Overview
End-to-end recipes for the four common integrations.
Four end-to-end recipes, each written against endpoints that exist today. Every field name is the real one, and every sample runs.
The guides
| Guide | What it covers | You need |
|---|---|---|
| Create an order | Resolving a customer and variants, placing the order idempotently, and reading what comes back. | orders:write, products:read |
| Sync inventory to an ERP | The updated_after + cursor pattern, checkpoints that survive a crash, and why offset paging is not offered. | products:read, inventory:read |
| Handle webhooks idempotently | Verify, de-duplicate, upsert, answer fast — the whole receiver. | A webhook endpoint |
| Build a custom storefront | Reading the catalogue, checking availability, taking an order and recording payment. | Read scopes, orders:write, payments:write |
Before any of them
- Create a key with only the scopes that guide needs (Authentication). Start with a store key.
- Export it as
SALAF_API_KEY— every sample in these docs reads it from the environment rather than inlining it. - Point at
/ext/v1—https://api.salafems.com/ext/v1. The shorter/v1alias is not deployed yet.
export SALAF_API_KEY="salaf_sk_YOUR_API_KEY"
curl -sS "https://api.salafems.com/ext/v1/products?limit=1" \
-H "Authorization: Bearer $SALAF_API_KEY"If that returns a product, you are ready for any of the four.
The patterns they share
Every integration in this list ends up leaning on the same four things, so they are worth learning once:
- Cursor pagination —
limit+starting_after+meta.has_more. - Incremental sync —
updated_afterwith a watermark. - Idempotent writes — one key per logical operation.
- One error shape — branch on
code, log therequest_id.