The EyeOnTask API

The API is how another system puts work into EyeOnTask without anybody retyping it. A CRM closes a deal and the job appears here. A booking form takes an enquiry and it lands as a request. An ERP raises a service call and a fieldworker is scheduled for it.

It is a standard REST API: HTTPS, JSON in and JSON out, an Authorization header, and the usual HTTP status codes. Anybody who has integrated with a payment gateway or an accounting package will recognise the shape of it, and the same tools work — curl, Postman, whatever your language uses for HTTP.

This section is written for whoever is building that integration. If you are looking for a connection you can set up without code, see integrations for QuickBooks, Xero, Stripe, PayPal and the SMS gateway, or Zapier for connecting EyeOnTask to a few thousand other apps by clicking rather than coding.

What it can do, and what it cannot

The API is deliberately narrow. It is a way in, not a general-purpose door onto your account, and knowing the boundary before you design saves rebuilding later.

It can:

• create a job — see creating a job
• create a request or lead — see creating a request
• read the reference lists a job needs: job types, priorities, countries, states — see reference data
• look up a customer, their sites and their contacts — see finding a customer

It cannot:

• read a job or a request back, or its status, after creating it
• update, cancel or delete anything
• push you a notification when something changes — there are no webhooks

Anything not documented in this section is out of scope, and calling it returns 501. That is true even for endpoints a REST API would normally be expected to have: the answer is what this section lists, not what the convention suggests.

What that means for your design

Nothing comes back out. Once a job is created, its life happens inside EyeOnTask — dispatched, accepted, worked, completed — and none of it is visible to the system that sent it. Do not build a screen in your CRM that shows EyeOnTask job status, because there is nothing to fill it with.

Nothing will call you. No webhook fires on any event. An integration that waits for one waits forever, and polling will not help either — the lookup endpoints do not carry status.

If your workflow genuinely needs status back, say so before you build around the gap rather than after: it is a question for support, not something to engineer around.

The base URL

Every call goes to your own subdomain:

https://{sub_domain}.eyeontask.com/en/eotServices/api/v1

The examples through this section write that as {BASE_URL}. Your integration credential comes with the exact address — use that rather than assembling one.

HTTPS only. A request over plain HTTP is rejected with 403 HTTPS_REQUIRED, and by then the credentials have already crossed the network unencrypted — so that key is compromised and has to be replaced.

There is no test environment

Every call runs against your live production account. There is no sandbox.

That is the single most important thing on this page, because it changes how you develop:

• Test with data you do not mind existing — a real but harmless customer, a job you will delete afterwards.
• Prefix test records clearly in external_id — TEST-CRM-JOB-10001 — so they can be found and cleaned up later.
• Remember that a job you create is a job the office can see. Somebody may dispatch your test to a real fieldworker.

This applies to every endpoint here, including any added later.

Versioning

This is v1, and the version is in the path. Breaking changes arrive as a new path — /api/v2 — and v1 keeps working until you are told otherwise, with a deprecation date rather than a surprise.

Additions that break nothing — a new optional field, a new endpoint — can appear in v1 without the version changing. Write your integration so an unexpected field in a response is ignored rather than fatal.

An OpenAPI 3.0 specification is available if you want machine-readable definitions for code generation or a testing tool. Ask support for it.

The pages in this section

• API credentials — creating a key, the headers every call needs, and what to do if one leaks.
• Requests and responses — the envelope, pagination, dates and rate limits.
• Idempotency and retries — how to retry a create without creating it twice.
• Reference data — job types, priorities, countries and states.
• Finding a customer — the lookup endpoints and how matching works.
• Creating a job — POST /jobs, field by field.
• Creating a request — POST /requests, and its two identity modes.
• Errors — status codes, error codes and getting help.
• Quick start — the whole sequence as curl commands.