Your first call, and its error

A GET that works, then a POST that does not. That is the shape of every first hour with a Fusion API, and the second half is where the learning is. Start with the GET, because it proves four things at once: the URL is right, the credentials work, the service account has the role, and the resource exists in your release. If the GET fails, none of the rest is worth attempting, and the failure tells you which of the four it was: 401 is authentication, 403 is authorisation, 404 is the URL or the release. Then the POST, which will fail, and the response is the lesson. A FUSION ERROR NAMES THE CONSTRAINT RATHER THAN THE MISTAKE. "A valid value is required for attribute X" does not mean X is missing — it frequently means X was supplied and did not resolve, which is a different problem entirely.…

In this module: Module 10 · REST and SOAP: calling Fusion, and being called

1. 1What Fusion exposes, and what it does not
2. 2REST vs SOAP: choosing without arguingFree preview
3. 3Authentication and the service account
4. 4Reading the REST API catalogue
5. 5Your first call, and its error
6. 6Payloads, child resources and partial updates
7. 7Bulk operations and rate limits
8. 8Fusion calling out: business events
9. 9Idempotency and retries
10. 10Versioning and surviving a quarterly update
11. 11What breaks: five integration failures
12. 12Lab briefing · Read, write and break an integration