## TL;DR
A Sift apply_decision 404 usually means the decision id and the order do not line up: the decision was created by a different workflow, in a different environment, or the order was never sent with the matching user and order identifiers. Pull the decision from the console, confirm its workflow and environment, and apply it using the exact decision id and the same identifiers from the original event. Applying a decision from workflow A to an order scored by workflow B will 404 every time.

```text
sift apply_decision api returned 404 decision not found
```

## Use this when
- apply_decision returns 404 for a decision you can see in the Sift console.
- Decisions were created after a workflow copy or a new workflow version.
- Test and live keys or environments are mixed in the integration.

## Not for this skill when
- The order itself was never sent to Sift. Send the order event first, then decide.
- The 404 is on a score request for an unknown user. That is a different endpoint contract.

## Steps
1. Copy the exact decision id from the console event view for the failing order and compare it character for character with the id in your request. Verify: the two ids match, or you found the mismatch.
2. Confirm the decision belongs to the workflow that scored the order and that both the original event and the apply call use the same environment keys. Verify: workflow name, version, and environment all match across the event and the call.
3. Check the identifiers: apply with the same user id and order id sent in the original transaction event, not an internal database id. Verify: the request identifiers equal the event identifiers.
4. Retry the apply call once the lineage matches and confirm the decision state changes in the console timeline. Verify: the console shows the decision as applied with your source noted.
5. Log workflow name, version, and decision id with every automated apply in your system so the next 404 can be diagnosed from logs alone. Verify: a sampled applied decision can be traced end to end in your logs.

## Variant phrasings
### sift decision not found 404 on apply
Error first phrasing.
### cannot apply sift decision to order
Action phrasing.
### sift workflow decision id mismatch
Mismatch phrasing.

Compatibility: Sift Decisions API across payment, account, and content workflows. Decision ids are scoped to a workflow and environment, which is the root of most 404s.

## Why it happens
Sift decisions are not global objects. They are produced by a specific workflow run for a specific entity, so the apply endpoint resolves the id only inside that scope. Integrations that store a bare decision id without its workflow and environment lose the scope and fail as soon as a second workflow or a copied workflow enters the picture.

## Edge cases / pitfalls
- Workflow copies get new decision ids for the same display names. A name match is not an id match.
- Sandbox decisions cannot be applied in production and the error gives no hint of that. Check the key prefix first on any new deploy.
- Decisions expire from the apply window in some configurations. A very old decision can 404 like a wrong one.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BltU0nMmVcYQdedYaZOZZg