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

What this page is

This page records what SeedLink’s production integration observed on the Rhode Island METRC API while a cultivator’s flower went out for remediation and came back, dated, with the read-only call behind each observation. It is not METRC documentation and it is not regulatory guidance: it describes how the API behaved for licensed Rhode Island cultivators on the dates given.

The observations were made for one reason. SeedLink keeps a cultivator’s active METRC packages on a live wholesale menu, and a sync that cannot tell a remediation departure from a sale deactivates flower that, on the observed routine, is back about a day later. Telling the two apart, and noticing the return, is what every question below was asked to settle. The answers are about METRC; the menu is only why they were asked.

Counts belong to one or two facilities on one day and move with every transfer. The field names, the endpoints, and the order in which things become visible are what this page is about. Other states run their own METRC instances and can differ on every point below.

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

What a remediation round trip looks like in METRC

When flower needs treatment, for example after a failed or at-risk microbial result, the cultivator transfers it out to a treatment partner. The partner treats it and transfers it back about a day later, usually under a new package tag. SeedLink watched this happen live at one Rhode Island production cultivator in July 2026, and at that facility the round trip is routine rather than an exception.

In METRC the trip is two transfers, an outgoing one from the cultivator and an incoming one back to it, and the outgoing transfer’s deliveries carry a type. That type is what separates a remediation trip from the two other reasons a package leaves a cultivator facility: a sale and a lab sample.

The type is enough on its own. A rule that says "hold the flower while it is on a Remediated Transfer" needs no list of partner facilities to compare the destination against, and no rule about which recipients are dispensaries. Nothing about the destination has to be known.

The only signal that says a package is out

Every flag whose name suggests it marks remediation was read while the package sat on the outgoing transfer, at the cultivator above in July 2026. All of them read false. The one field that carried the information was ShipmentTypeName on the outgoing transfer’s deliveries, reached in two calls: GET /transfers/v2/outgoing for the transfer list, then GET /transfers/v2/{id}/deliveries for each transfer on it.

The lag on GET /packages/v2/transferred deserves its own sentence, because it is the endpoint an integration reaches for first when a package disappears from the active list. A package dispatched a minute ago is not in it. It appears there only after the recipient accepts the manifest. GET /transfers/v2/outgoing shows the transfer immediately, so departures are read there, and /transferred is at most a later confirmation.

The flags are not subtly wrong; they are simply false, and the on-hold list is simply empty, for the whole time the package is away. An integration that waits for any of them to change never sees the trip at all.

Three ways a package comes home

The package comes back on an incoming transfer, and how it surfaces afterwards depends on whether it kept its tag. Three shapes were observed at the cultivator above in July 2026, and each one is matched to the package that left by a different field.

The second shape is the usual one. What comes back is a new package under a new tag, received from the partner’s facility. ReceivedFromFacilityName is the field that ties it to the trip, because it names the facility the original package was shipped to, and ReceivedFromManifestNumber names the return manifest. Matching on that facility and the strain is what lets a record built around the old tag carry over to the new one, with its orders, prices and images.

The third shape happens when the cultivator re-tags the returned package at home. The returned package then survives only as an ancestor, and the new package’s SourcePackageLabels is the sole link back to the tag that left. Strain and category are checked as well as lineage, because a child that is no longer flower is not the same product coming home, which is the case the next section is about.

The return that no list shows

On 2026-07-16 one package at the cultivator above came home under the same tag at 11:28 UTC. By 11:40 UTC it had been ground in full into a different product in a different category, and the package was finished at 0 g. SeedLink reads the facility every hour, and both events fell between 2 hourly reads, so the package never reappeared in GET /packages/v2/active. Because the new product was in a different category, no child package of the same strain in the flower category ever existed either. Every list-based check in the previous section returned nothing, and the record waiting for the package to come back sat for 6 days while METRC showed it home and consumed.

A direct read of the departed tag answers this case, and its meaning changes at each stage of the trip.

The third row is the trap inside the fix. A live package with a receive stamp looks like a return, and acting on it as one re-lists flower that may not be at the facility. The active list, read on every sync, is the right place to notice a live same-tag return; the direct read exists for the case where nothing in any list can see the package, and it acts only on a definitive answer. A read that fails, or a 401, changes nothing.

The incoming side closes the loop

The July observations were made from the outgoing side and from the package lists, which is why the same-tag return above was invisible to them. On 2026-07-25 a read-only sweep of 49 endpoints at two Rhode Island production cultivators read the incoming side, and it turns the round trip from a chain of inferences into positive list evidence.

So "did it come back?" has a list answer after all: the incoming transfer that names the label, and, for a package consumed on arrival, the inactive list that carries its finished date. Neither depends on the package ever being seen in the active list. The pairing is by label.

The sweep paired by label and counted 43 of 43. It did not record how many of those returns kept their tag and how many came back under a new one, so the count says that the incoming side names the shipped label; it does not say which return shape each trip took.

SeedLink does not yet read GET /packages/v2/intransit. It is listed because the sweep found it, and because it is the endpoint that answers the one question the direct read cannot: whether a package that came back has since left again.

Why these observations were made

SeedLink syncs a cultivator’s active METRC packages into a live wholesale menu, and a package that drops out of the active list is normally deactivated on the menu, because the usual reason it dropped out is that it was sold. Flower on a remediation trip drops out of the active list too, for about a day, and the cultivator keeps selling it: the routine is that it comes back. So the sync had to tell a remediation departure from a sale, keep the row sellable with its count frozen while the package was away, and reconnect the row to the new tag on return so the history tied to the old tag carries over. Each rule on this page is the answer to one of those needs, and the same-tag return that no list showed is the case that added the direct read.

Check it yourself with read-only calls

The whole question is answerable with GETs and no writes. The first two calls say whether a package is out for remediation; the rest say whether it came back, and whether it has left again.

GET https://api-ri.metrc.com/transfers/v2/outgoing?licenseNumber=<your license>
Authorization: Basic <base64 of VENDOR_KEY:USER_KEY>

for each transfer in the response:
  GET https://api-ri.metrc.com/transfers/v2/<transfer Id>/deliveries?licenseNumber=<your license>
  for each delivery:
    out_for_remediation = (delivery.ShipmentTypeName == "Remediated Transfer")
    GET https://api-ri.metrc.com/transfers/v2/deliveries/<delivery Id>/packages?licenseNumber=<your license>
    note every package label on a delivery where out_for_remediation is true

then, for each label noted:
  GET https://api-ri.metrc.com/transfers/v2/incoming?licenseNumber=<your license>
    a later incoming transfer that names the label is the return
  GET https://api-ri.metrc.com/packages/v2/inactive?licenseNumber=<your license>
    a row for the label with quantity 0 and IsFinished true is a return that was consumed
  GET https://api-ri.metrc.com/packages/v2/<label>?licenseNumber=<your license>
    HTTP 401 while it is away; HTTP 200 with quantity 0 or IsFinished true once it is back and used up
  GET https://api-ri.metrc.com/packages/v2/intransit?licenseNumber=<your license>
    a row for the label means it has left the facility again

If a label is on a Remediated Transfer delivery and absent from GET /packages/v2/transferred, that is the lag, not a contradiction. If it is absent from GET /packages/v2/active after an incoming transfer named it, read the inactive list before concluding that it never came back.

Sources and how to cite this page

• Live remediation round trip at one Rhode Island production cultivator, July 2026: GET /transfers/v2/outgoing and its deliveries, the package flags, GET /packages/v2/onhold and GET /packages/v2/transferred, read-only.
• Same-tag return of 2026-07-16 at the same facility, reconstructed from hourly sync records and GET /packages/v2/{label}, Rhode Island production.
• Read-only sweep of 49 endpoints at two Rhode Island production cultivators, 2026-07-25: GET /transfers/v2/incoming, GET /transfers/v2/outgoing, GET /packages/v2/inactive, GET /packages/v2/intransit.
• SeedLink METRC field guide (docs/METRC.md), sections Remediation transfers and the Menu Hold, and Transfer types.

SeedLink, "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", observed 2026-07-25, revised 2026-09-20, https://www.seedlink.net/guides/metrc/remediation-transfers

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/remediation-transfers/data.json

Related

• A METRC transfer template becomes a manifest only when a person dispatches it in METRC Connect: Rhode Island exposes no dispatch endpoint
• METRC lab results in Rhode Island follow a package that was created before the results 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
• 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
• All metrc field guides for rhode island
• Methodology: what SeedLink publishes and what it does not