A METRC transfer template becomes a manifest only when a person dispatches it in METRC Connect: Rhode Island exposes no dispatch endpoint

What this page is

This page records how a transfer moves from an API-created template to a dispatched manifest on the Rhode Island METRC API, as SeedLink’s integration observed it, with the date and the call behind each statement, or a note where the record holds no date. It is not METRC documentation and it is not regulatory guidance: it describes what the endpoints returned to licensed Rhode Island cultivator credentials on the dates given.

The verbs that returned 404 and 405 are listed because an integrator reaches for them first and the documentation does not say they are absent. Field names, response shapes and the order of the steps are what this page is about; the counts on one delivery belong to that delivery on that day. Other states run their own METRC instances and can differ on every point below.

Nothing here mutates a transfer. SeedLink creates templates, reads what METRC Connect produced, and surfaces any difference to the cultivator. METRC is the legal record and the cultivator owns every correction to it.

How every number on this site is observed, dated and bounded is on the methodology page, which also lists what SeedLink does not publish.

The lifecycle, stage by stage

A wholesale shipment in Rhode Island passes through two METRC records, not one. The template is the plan; the outgoing transfer is the shipment. They have separate Ids from separate counters, manifest numbers of different shapes, and the only field that ties them together is OriginatingTemplateId on the transfer.

Every action in the second column after the first row is a METRC Connect action. The API creates the plan and reads each later state; it never advances one.

Creating the template: what comes back, and what a template holds

POST /transfers/v2/templates/outgoing creates the template. On 2026-04-24 the Rhode Island sandbox answered 200 with {Ids: [N]}, and the id in that response was unreliable: SeedLink needed a follow-up GET /transfers/v2/templates/outgoing to find the template it had just created. That list gives each template its own Id and a ManifestNumber prefixed with T-, such as T-0000000001. There is no PDF at this stage; the manifest PDF endpoint takes the Id of the dispatched transfer, which does not exist yet.

A template carries no quantity. Read on 2026-09-03 on both the sandbox and production, each package on a template holds four fields and nothing about how much is inside.

The manifest ships whatever the package holds. That is why there is no way to edit a quantity on a manifest, and why a quantity correction is made on the package instead; the section on the read-only transfer below shows what that looks like.

The template also names a transfer type, and the name is not free text. Probed from GET /transfers/v2/types on Rhode Island cultivator and lab licenses (the day of that probe is not in our record), a wholesale sale from a cultivator to a dispensary is an Unaffiliated Transfer, or an Affiliated Transfer when the two facilities share ownership. The bare name Transfer is refused with 400 and the message Transfer Type Name not specified.

A lab credential therefore cannot create a wholesale manifest at all, and on 2026-07-26 a POST /transfers/v2/external/incoming from a lab license on the sandbox returned 401. Keep the credential that builds templates pointed at the cultivator license.

No endpoint dispatches a template

The template does not promote itself, and nothing in the API promotes it. The cultivator clicks "Start" in the METRC Connect web interface, which is the regulatory human-in-the-loop step standing for the physical loading of the truck. SeedLink probed every verb that might have stood in for that click, on two days, and none exists.

What the API does buy is a shorter click path. With the template staged first, the dispatch step in METRC Connect was about 3 clicks on 2026-07-26. The API’s contribution to dispatch is that the plan is already on the screen when the person gets there.

A template is not a shipment. An integration that marks an order as shipped when the template is created, or that treats an empty poll of GET /transfers/v2/outgoing as anything other than "not dispatched yet", is reporting a truck that has not left.

After dispatch: a second record with its own Id

When the person clicks "Start", METRC creates a real outgoing transfer. It has its own Id, a plain-numeric ManifestNumber (0000000817 on the sandbox on 2026-04-24, against the template’s T-0000000001), and OriginatingTemplateId set to the template’s Id. GET /transfers/v2/outgoing lists it. SeedLink matches on OriginatingTemplateId first and falls back to Name, because the template name it writes is unique per order.

The two Ids come from independent counters. A template Id and an outgoing-transfer Id can carry the same number and name unrelated records, which is harmless when reading lists and dangerous on the PDF endpoint, described in the next section.

The row on GET /transfers/v2/outgoing is thin. On 2026-06-04, on production, the rows read carried a null RecipientFacilityName; the recipient is on GET /transfers/v2/{id}/deliveries, and the packages that shipped are on GET /transfers/v2/deliveries/{deliveryId}/packages. After dispatch, that second list is the real shipped list, and it is the one to diff against whatever the integration recorded when it built the template.

The package set can differ from the template. Cultivators legitimately edit it while they are in METRC Connect: they swap a package, add a ride-along, or drop one that missed the van. SeedLink learned this on one order in June 2026, when the dispatched manifest carried a package set that differed from the template it had built, and the order went on describing the plan instead of the shipment until someone looked.

The posture on any difference is to surface it, never to mutate. METRC is the legal record, the cultivator owns the correction, and a wrong automatic fix to a shipping record is worse than a warning that gets dismissed. SeedLink shows the difference on the order and changes nothing in METRC.

The manifest PDF takes the transfer Id, and only with a license number

GET /transfers/v2/manifest/{id}/pdf returns the manifest. The {id} is the outgoing-transfer Id: not the template Id, and not the manifest number. It also requires ?licenseNumber=, which the documentation does not mention. Without it, on 2026-04-24, the sandbox returned 404 with the body No HTTP resource was found that matches the request URI /transfers/v2/manifest/N/pdf., a message that names the path and not the missing parameter.

The response is not a binary PDF. It is JSON with the file inside it as base64.

The collision hazard follows from the independent counters. On 2026-04-24, GET /transfers/v2/manifest/1/pdf on the sandbox returned a pre-seeded demo manifest for an unrelated facility in another state, with no error, because the sandbox holds a demo transfer at that Id. An integration that passes its template Id to this endpoint gets a real PDF for somebody else’s shipment and no signal that anything is wrong. SeedLink refuses the PDF request while the manifest number it holds still starts with T- (its own 409, template_not_dispatched), so a template Id can never reach the endpoint.

A dispatched transfer is read-only, and the quantity lives on the package

Once dispatched, the transfer is read-only to the API, permanently. On 2026-09-03 SeedLink tried the writes on both the sandbox and production.

So the API cannot change what a dispatched manifest says, and it cannot change the package under it either. METRC Connect can. On 2026-09-02 one Rhode Island cultivator dispatched a manifest; on 2026-09-03, with the shipment in transit, they adjusted one of its packages in METRC Connect, and the transfer’s ShippedQuantity followed on its own, from 100 to 79. The manifest was never edited. The package was, and the manifest reports the package.

That is the rule to carry: you never edit a manifest, you adjust the package, and once the transfer is dispatched only a person in METRC Connect can do it. The template’s four per-package fields have no quantity for the same reason. The quantity is the package’s.

Reading the trip: departure, receipt, rejection and return

Every later state is written by METRC Connect and read by the integration. Two stamps on the delivery carry the trip: ActualDepartureDateTime set means the shipment is in transit, and ReceivedDateTime set means it was delivered. Dispatch and both stamps are METRC Connect actions.

A package the recipient refuses at the door walks three states, and the third is one METRC’s documentation does not show. On 2026-07-29, on production, one delivery’s ShipmentPackageState read Shipped, then Rejected at receipt, then Returned once the shipper recorded the return leg, at which point the delivery’s RejectedPackagesReturned flipped true.

The returned package landed back on the shipper’s side as its own active package. An integration that treats every dispatched package as gone for good misses it.

/packages/v2/transferred is the other place a shipment shows up, and it lags. A just-dispatched package is absent from it until the recipient accepts the manifest, so departures are read from GET /transfers/v2/outgoing, where the transfer appears at dispatch. Once the recipient has accepted, /packages/v2/transferred carries the shipped package with ShipperWholesalePrice and ReceiverWholesalePrice, SourcePackageLabels and ManifestNumber, in a flat schema with no nested Item. On 2026-06-04, on production, the wholesale price per shipped package appeared there once the recipient had accepted.

Check it yourself with four read-only calls

The whole lifecycle is readable with GETs and no writes.

GET /transfers/v2/templates/outgoing?licenseNumber=<your license>
  each template: Id, ManifestNumber starting with T-

GET /transfers/v2/outgoing?licenseNumber=<your license>
  each dispatched transfer: Id, a plain-numeric ManifestNumber, OriginatingTemplateId
  match OriginatingTemplateId to the template Id; RecipientFacilityName can be null here

GET /transfers/v2/{transferId}/deliveries?licenseNumber=<your license>
  the recipient, ActualDepartureDateTime, ReceivedDateTime, RejectedPackagesReturned,
  DeliveryPackageCount, DeliveryReceivedPackageCount

GET /transfers/v2/deliveries/{deliveryId}/packages?licenseNumber=<your license>
  what shipped: PackageLabel, ShippedQuantity, ShipmentPackageState, ReceivedQuantity

If the transfer you are looking for is absent from the second call, it has not been dispatched, whatever the template says. If it is present, ActualDepartureDateTime is the stamp that says it left and ReceivedDateTime the stamp that says it arrived. And if the package list from the fourth call does not match the template you wrote, the list is right and the template is history.

Sources and how to cite this page

• Rhode Island sandbox transfer-lifecycle probes, 2026-04-24 and 2026-07-26: creating a template, reading it back, every dispatch verb, the manifest PDF endpoint (the SeedLink transfers module and its probe scripts).
• Rhode Island production reads of GET /transfers/v2/outgoing, its deliveries and delivery packages, 2026-06-04 and 2026-07-29, read-only.
• Rhode Island sandbox and production writes against a dispatched transfer and a transferred package, 2026-09-03, plus one cultivator’s adjustment in METRC Connect read back through the API the same day.
• SeedLink METRC field guide (docs/METRC.md), section Transfers & Manifests: transfer types, transfer lifecycle, manifest and order reconciliation, manifest PDF endpoint, transferred-package pricing, remediation transfers. The transfer-types probe and the June 2026 dispatch divergence are recorded there without a day.

SeedLink, "A METRC transfer template becomes a manifest only when a person dispatches it in METRC Connect: Rhode Island exposes no dispatch endpoint", observed 2026-09-03, revised 2026-09-20, https://www.seedlink.net/guides/metrc/transfer-template-to-manifest

Every figure above carries the date it was observed and the environment it was observed in. A count belongs to one facility on one day; the field names, orderings and error messages are the durable part.

Machine-readable copy of this page, with the same facts, dates and sources: /guides/metrc/transfer-template-to-manifest/data.json

Related

• The Rhode Island METRC API returns an empty HTTP 200 when the required date filters are missing, and several other traps produce the same empty answer
• METRC package adjustments in Rhode Island: Quantity is the new total, not a delta, and the adjustments log reports the difference
• METRC remediation transfers in Rhode Island: the outgoing delivery’s ShipmentTypeName is the only sign a package is out, and the incoming transfer is the proof it came back
• Combining two METRC packages of one item in Rhode Island is one POST with two ingredients, and the drained sources stay active until you finish them
• All metrc field guides for rhode island
• Methodology: what SeedLink publishes and what it does not