Skip to content

What you need from the other service

Every integration is one you set up yourself against the other service’s own API. Half an hour with their documentation before you open the editor saves a lot of guessing, and this is the list of what to come back with.

Find the exact URL and the method. WorkWing sends GET, POST or PUT over HTTPS.

Write down which parts of the URL change per job. Anything that varies becomes an input parameter and goes into the URL as a template variable, so a path like /lines/{id}/test tells you that you need an input called line_id.

For a GET, that’s usually just the URL. For a POST or PUT you need the shape of the body, which becomes your body template.

Work out where each value comes from. Some come from the person on site, typed into the job form. Some come from the job or the customer record, so WorkWing can fill them in without anyone typing. Some are fixed for your organisation and never change.

Most APIs want one. Find out what it looks like on the wire, because that’s what you’ll be typing as a header: a bearer token, a key in a custom header, a name and password.

Worth noting the hostname the credential is meant to reach, too. You can record it as an Allowed destination when you store the secret, and WorkWing then sends the credential nowhere else. It’s optional, but it’s the difference between a key that works anywhere and one pinned to the service it belongs to.

Ask for one, or call the endpoint yourself and keep the output. You need it for two things: working out the path to each value you want, and writing the transform expression if the answer is buried.

Then decide which values matter to the person doing the job. A line test might return thirty fields and the engineer needs two of them. Those two become your output parameters.

If the service answers in a second or two, the integration is Sync and the answer appears on the form immediately.

If it queues the work and answers later, it’s Async, and you need one more thing from their documentation: how to tell them where to send the result. WorkWing gives you that address as {{callback_url}}, and you put it in whatever field their API expects.

A lookup is the common case. GET, sync, one input, two or three outputs, a header holding an API key. Address validation, invoice lookup, stock check.

A long check is the other. POST, async, a body carrying the reference and the callback address, and a completion field so WorkWing knows when the final callback has arrived. Line tests, provisioning, anything with equipment at the far end.

Custom integrations is the editor, field by field. Bring your notes.