SitterIT Mobigo REST API — integration guide

Read and write in Mobigo over HTTP: tasks, customers, products, quotes, orders, contracts, time, materials and documents.

Getting started

You need a clientId and an API key from whoever operates Mobigo. The key is shown once, when the integration is created.

First call

curl -H "Authorization: Bearer mk_..." \
     "https://mobigo-api.kundens-server.se/v1/whoami"

# → {"integration":"Webshop","tenant":"Demo","scopes":["tasks:read","tasks:write"]}

/v1/whoami tells you which integration the key belongs to and what it may do.

Create a task with materials and time

curl -X POST "https://mobigo-api.kundens-server.se/v1/tasks" \
     -H "Authorization: Bearer mk_..." \
     -H "Idempotency-Key: order-4711" \
     -H "Content-Type: application/json" \
     -d '{
           "customerNr": "10003",
           "taskText":   "Lift service",
           "materials":  [{ "productNr": "A10001", "quantity": 3 }],
           "times":      [{ "timeType": "Normal time", "hours": 2 }]
         }'

# → {"nr":"U039071","id":105933,
#     "materials":[{"id":44821,"productNr":"A10001"}],
#     "times":[{"id":100636,"timeType":"Normal time"}]}

The response carries an id for every line created. With that id the line can be updated directly through PATCH /v1/materials/{id} or PATCH /v1/times/{id}.

Authentication

Everything under /v1 requires Authorization: Bearer <value>. The value is either the key itself or a token. Both give the same company, the same permissions and the same IP restriction.

Tokens are fetched with client_credentials:

curl -X POST "https://mobigo-api.kundens-server.se/v1/token" \
     -H "Content-Type: application/json" \
     -d '{"clientId":"f287ea5c…","clientSecret":"mk_…"}'

# → {"access_token":"mt_…","token_type":"Bearer","expires_in":3600,
#    "scope":"tasks:read tasks:write"}

Fetch a new one when expires_in has passed, or when a call answers 401. There is no refresh token — fetching is one call, and costs less than keeping track of two kinds of token.

Where does the key come from?

It is created by whoever operates Mobigo, on the server, with SitterIT.Mobigo.Api keys create. You cannot create it yourself — by design: the key is tied to a company and to a Mobigo signature, and both are the customer's decisions to make.

Ask for three things:

Say at the same time which scopes you need — they are set when the key is created and cannot be widened afterwards without a new key.

Scopes

Every resource has two: <resource>:read and <resource>:write. Without the scope the API answers 403.

On top of them, Mobigo's own permissions apply to the signature the key works as. A wide scope therefore never grants more than that signature may do in Mobigo.

Tasks

POST /v1/tasks accepts the task's whole writable surface. Only customerNr is required. An omitted field is left untouched.

curl -X POST "https://mobigo-api.kundens-server.se/v1/tasks" \
     -H "Authorization: Bearer mk_..." \
     -H "Idempotency-Key: order-4712" \
     -H "Content-Type: application/json" \
     -d '{
           "customerNr":      "10003",
           "taskText":        "Half-year service, lift 3",
           "taskNote":        "Customer wants notice the day before.",
           "customerRef":     "Order 88214",
           "ownerSign":       "AN",
           "userSigns":       ["AN", "PL"],
           "planStartDate":   "2026-09-14",
           "planStopDate":    "2026-09-16",
           "planDateType":    "FromTo",
           "estimatedTime":   6.5,
           "projectNr":       "P-204",
           "priorityName":    "High",
           "object1Nr":       "LIFT-0031",
           "customT1":        "Service contract",
           "extraFields":     { "Visma_Ordernr.": "VO-4711" },
           "materials":       [{ "productNr": "A10001", "quantity": 3 }],
           "times":           [{ "timeType": "Normal time", "hours": 4 }]
         }'

Orders and quotes

Both are created with their lines in one call. If any line fails the whole record is rolled back — half an order looks like a real one and never gets completed.

An order with lines

curl -X POST "https://mobigo-api.kundens-server.se/v1/orders" \
     -H "Authorization: Bearer mk_..." \
     -H "Idempotency-Key: order-B-4711" \
     -H "Content-Type: application/json" \
     -d '{
           "customerNr":       "10018",
           "supplierNr":       "L00001",
           "userSign":         "AN",
           "customerOrderer":  "Anna Beställare",
           "orderDate":        "2026-08-20",
           "deliveryDate":     "2026-09-14",
           "deliveryName":     "Ekehamn Bygg AB",
           "deliveryAddressLine1": "Verkstadsgatan 8",
           "deliveryPostalCode":   "417 05",
           "deliveryCity":         "Göteborg",
           "internalNote":     "Call before delivery",
           "lines": [
             { "productNr": "10053",  "quantity": 5, "supplierNr": "L00001" },
             { "productNr": "A10001", "quantity": 2 },
             { "productNr": "A10002", "quantity": 1, "price": 1250 }
           ]
         }'

# → { "Nr": "B00065", "Status": "Planned", "CustomerNr": "10018",
#     "SupplierNr": "L00001", "OrderDate": "2026-08-20T00:00:00", … }

The number comes from Mobigo's number series. orderDate defaults to today, and the product's unit and name are taken from the product register.

Lines on an existing order

POST https://mobigo-api.kundens-server.se/v1/orders/B00065/lines
Idempotency-Key: line-B00065-4

{ "productNr": "A10003", "quantity": 2, "deliveryDate": "2026-09-20" }

# → { "id": 10011, "orderNr": "B00065", "productNr": "A10003", "totalPrice": 1900 }

Changing an order

PATCH touches only the fields you send. The rest are left as Mobigo has them.

curl -X PATCH "https://mobigo-api.kundens-server.se/v1/orders/B00065" \
     -H "Authorization: Bearer mk_..." \
     -H "Idempotency-Key: order-B00065-delivery" \
     -H "Content-Type: application/json" \
     -d '{ "deliveryDate": "2026-09-21",
           "internalNote": "Delivery moved, customer informed" }'

Individual lines are changed by their id:

PATCH https://mobigo-api.kundens-server.se/v1/orderlines/10011
Idempotency-Key: line-10011-quantity

{ "quantity": 3, "discountPct": 10 }

A quote with materials and time

A quote carries material and time lines, like a task — not order lines.

curl -X POST "https://mobigo-api.kundens-server.se/v1/quotes" \
     -H "Authorization: Bearer mk_..." \
     -H "Idempotency-Key: quote-4711" \
     -H "Content-Type: application/json" \
     -d '{
           "customerNr":  "10018",
           "description": "Lift service, half year",
           "ownerSign":   "AN",
           "materials": [
             { "productNr": "A10001", "quantity": 3 },
             { "productNr": "A10002", "quantity": 1 }
           ],
           "times": [
             { "timeType": "Normal time", "hours": 4 },
             { "timeType": "Normal time", "hours": 2.5 }
           ]
         }'

quoteDate defaults to today and the validity to 30 days when omitted. Get the time types' names from GET /v1/timetypes.

Reading the lines

Material and time lines hang off different kinds of record. ownerType says which — task, quote, order or contract. Omitted together with ownerNr, a task is assumed.

GET https://mobigo-api.kundens-server.se/v1/materials?ownerType=quote&ownerNr=Q00005
GET https://mobigo-api.kundens-server.se/v1/times?ownerType=quote&ownerNr=Q00005
GET https://mobigo-api.kundens-server.se/v1/orderlines?orderNr=B00065

Every line says what it hangs off, in OwnerNr and OwnerType.

Idempotency-Key

A call can arrive without its response getting back. Without protection the retry gives the customer two identical tasks.

Idempotency-Key is a string you choose per operation. When the same key comes back with the same content, the API answers with the first response instead of doing the work again.

The response echoes the key back and says whether it is a stored response. The echo is present on error responses too.

Idempotency-Key: order-4711
Idempotency-Replayed: false     ← the call ran now
Idempotency-Replayed: true      ← you got the receipt for an earlier call

Idempotency-Key: order-4711   → {"nr":"U039075"}
Idempotency-Key: order-4711   → {"nr":"U039075"}   ← same task, nothing new
Idempotency-Key: order-4712   → {"nr":"U039076"}   ← new order, new task
Idempotency-Key: order-4711 + changed content → 409
without the header                            → 400

Every writing call requires the header: POST and PATCH, on all resources.

Paging

The response looks the same for every resource:

{ "items": [ … ], "nextCursor": "105935", "page": 1, "total": 65233 }

limit defaults to 50 and is capped at 500. total is null for the resources Mobigo cannot count.

Cursor

Constant speed however deep you go. Use it when syncing.

GET https://mobigo-api.kundens-server.se/v1/customers?limit=500
# → "nextCursor": "105935"
GET https://mobigo-api.kundens-server.se/v1/customers?limit=500&cursor=105935

nextCursor is where the previous page ended. null means there is nothing more to fetch.

Page number

GET https://mobigo-api.kundens-server.se/v1/customers?limit=50&page=3

Fetch only what changed

GET https://mobigo-api.kundens-server.se/v1/tasks?modifiedSince=2026-08-19T00:00:00Z

Store Modified from the previous run and ask for everything changed since.

Contacts and addresses

Contact persons and extra addresses are records of their own, hanging off a customer, a supplier or an object. They are identified by Id, not by a number.

Contacts on one customer

GET https://mobigo-api.kundens-server.se/v1/contacts?customerNr=10003

# → { "items": [ { "Id": "11311", "CustomerNr": "10003", "Name": "Linus Sedin",
#                  "Position": "Property manager", "Mobile": "070-1234567",
#                  "Email": "[email protected]", "MostImportant": true } ],
#     "nextCursor": null, "page": 1 }

All contacts

Without customerNr the whole register is listed. name is a free text search on the name.

GET https://mobigo-api.kundens-server.se/v1/contacts?limit=500
GET https://mobigo-api.kundens-server.se/v1/contacts?name=Sedin
GET https://mobigo-api.kundens-server.se/v1/contacts?modifiedSince=2026-08-01T00:00:00Z

Adding a contact

POST https://mobigo-api.kundens-server.se/v1/contacts
Idempotency-Key: contact-10003-linus

{ "customerNr": "10003", "name": "Linus Sedin",
  "position": "Property manager", "email": "[email protected]",
  "mobile": "070-1234567", "mostImportant": true }

Contacts when the customer is created

Send them in the same call. If any contact is rejected the whole customer is rolled back.

POST https://mobigo-api.kundens-server.se/v1/customers
Idempotency-Key: customer-storfors

{
  "name": "Storfors Service AB",
  "addressLine1": "Storgatan 1",
  "postalCode": "412 50",
  "city": "Göteborg",
  "contacts": [
    { "name": "Linus Sedin", "position": "Property manager",
      "email": "[email protected]", "mostImportant": true },
    { "name": "Anna Ek", "position": "Finance", "email": "[email protected]" }
  ]
}

The number was omitted, so Mobigo's number series assigned it. The response contains the customer with its Nr.

Supplier contacts

Same fields, own path: /v1/suppliercontacts with supplierNr.

Addresses

Extra addresses — delivery, invoice, visiting. The owner must be given, because the address table is shared between customers, suppliers and objects.

GET https://mobigo-api.kundens-server.se/v1/addresses?customerNr=10003
GET https://mobigo-api.kundens-server.se/v1/addresses?objectNr=O1-11840&level=1

Extra fields

The customer's own fields, defined in their Mobigo. They are named whatever the customer called them and always arrive as strings.

Which fields exist?

Every resource describes its extra fields: key, type, whether it can be written and which values a list field allows.

GET https://mobigo-api.kundens-server.se/v1/customers/extra-fields

# → { "items": [
#       { "Key": "Avtals_typ", "Name": "Contract type", "Category": "Contract",
#         "Type": "Combo", "Writable": true, "ReadOnly": false, "Computed": false,
#         "Options": ["Basic service", "Incentive", "On call"] },
#       { "Key": "Startdatum_avtal", "Name": "Contract start",
#         "Type": "Date", "Writable": true },
#       { "Key": "Region", "Name": "Region",
#         "Type": "Sql", "Writable": false, "Computed": true }
#     ],
#     "count": 59 }

Writable: false means a write is rejected — the field is either read only or computed by Mobigo. Options is present on list fields only.

The same path exists on every resource, tasks included: GET https://mobigo-api.kundens-server.se/v1/tasks/extra-fields.

Reading

GET https://mobigo-api.kundens-server.se/v1/customers/10003

# → {
#     "Nr": "10003",
#     "Name": "Storfors Service AB",
#     "ExtraFields": {
#       "Avtals_typ": "Helservice",
#       "Startdatum_avtal": "2024-01-01",
#       "Index_regleras": ""
#     }
#   }

Empty fields are included as empty strings, so you can see which fields exist. That is also how you get the exact names.

Writing on a resource

curl -X PATCH "https://mobigo-api.kundens-server.se/v1/customers/10003" \
     -H "Authorization: Bearer mk_..." \
     -H "Idempotency-Key: sync-10003-v4" \
     -H "Content-Type: application/json" \
     -d '{ "extraFields": { "Avtals_typ": "Delservice", "Avtals_nr": "A-9912" } }'

Writing on a task

The same object, in the same call that creates the task:

curl -X POST "https://mobigo-api.kundens-server.se/v1/tasks" \
     -H "Authorization: Bearer mk_..." \
     -H "Idempotency-Key: order-4713" \
     -H "Content-Type: application/json" \
     -d '{
           "customerNr":  "10003",
           "taskText":    "Service",
           "extraFields": {
             "Visma_Ordernr.": "VO-4711",
             "Avtals_typ":     "Helservice",
             "Startdatum":     "2026-09-14"
           }
         }'

The key is the field's name in the customer's Mobigo, exactly as it appears in ExtraFields when you read the record. Dots and underscores are part of the name. The value is always a string, dates and numbers included.

Errors you may get

Lookups

The values other calls require. They belong to the customer, so they cannot be listed in advance. All of them are read only — they are set in Mobigo's administration.

GET https://mobigo-api.kundens-server.se/v1/timetypes

# → { "items": [ { "Name": "Normal time", "Unit": "h", "BasePrice": 750,
#                  "InternalType": false, "SpecOptions": ["Diagnosis", "Replacement"] } ] }

The customer's own field names

Custom1–Custom4 are called something else at the customer. /v1/field-names says what.

GET https://mobigo-api.kundens-server.se/v1/field-names

# → { "items": [
#       { "DbFieldName": "CustCustom1", "UserFieldName": "Postal address",
#         "ListOnly": false, "Hidden": false },
#       { "DbFieldName": "TaskCustom1", "UserFieldName": "Service contract",
#         "ListOnly": true, "Hidden": false }
#     ] }

DbFieldName is the name this API uses. UserFieldName is the customer's label. Hidden means the field is not shown in Mobigo.

Location

Mobigo geocodes its own records, against the map service and the rules the customer has set up. This API reads that position and can ask Mobigo to recalculate it, but never geocodes on its own.

GET https://mobigo-api.kundens-server.se/v1/tasks/U039079/location

# → { "Latitude": 57.7089, "Longitude": 11.9746,
#     "Address": "Storgatan 1, 412 50 Göteborg",
#     "Status": "Ok", "SourceType": "Address", "Provider": "GoogleMaps",
#     "Fixed": false, "Ambiguous": false }

?locate=true recalculates the position first, from the task's customer, object or address. ?force=true redoes it even when a position already exists.

Latitude and Longitude are null when the record has no position. Status says why: NoAddress, AddressNotFound, AddressInvalid, Pending or Error.

Fixed position

For addresses that cannot be looked up. A fixed position is never overwritten by Mobigo's own geocoding.

PUT https://mobigo-api.kundens-server.se/v1/tasks/U039079/location
Idempotency-Key: pos-U039079

{ "latitude": 57.7089, "longitude": 11.9746,
  "address": "Building site, Ringön" }

The same two paths exist on every resource: /v1/customers/10003/location, /v1/objects1/O1-11840/location and so on.

Documents on a task

Three calls: attach, list and fetch. The list and the content are separate — a task can carry attachments of tens of megabytes.

POST /v1/tasks/U039079/documents
Idempotency-Key: attachment-4711

{ "name": "workorder.pdf", "contentBase64": "JVBERi0xLjQK..." }

201 { "id": 60728, "nr": "U039079", "name": "workorder.pdf" }

GET /v1/tasks/U039079/documents

{ "items": [ { "Id": 60728, "Name": "workorder.pdf", "DocType": "EMBED",
               "Kind": "embedded", "IsInternal": false, "HasContent": true,
               "Modified": "2026-08-19T22:41:23.72" } ],
  "count": 1 }

GET /v1/tasks/U039079/documents/60728

200 OK
Content-Type: application/pdf
Content-Disposition: attachment; filename=workorder.pdf
<the file's content>

Linked documents and print templates

Kind says what the document is:

Mobigo's own document handling does the work in all four cases. That is why Content-Type can be application/pdf even when the file name ends in something else — the type comes from the content, not from the name. If the name has no extension, the right one is added in Content-Disposition.

A link whose path is unreachable from the server gives 422 saying so, not an empty file.

Error codes

All errors are application/problem+json per RFC 9457.

{ "type": "https://sitterit.se/problems/command_failed",
  "title": "command_failed",
  "status": 422,
  "detail": "Ingen artikel med nummer FINNS-EJ." }

Tracing: X-Request-Id

Every response carries X-Request-Id. Error responses have the same value in the requestId field. Quote it in support cases.

{ "type": "https://sitterit.se/problems/command_failed",
  "title": "command_failed",
  "status": 422,
  "detail": "Ingen artikel med nummer FINNS-EJ.",
  "requestId": "8d1f55fc02754b1e" }

If you send your own X-Request-Id it is used instead and echoed back. Allowed characters are letters, digits and - _ . :, at most 64.

Resources

Every resource has the same shape: GET /v1/<resource> for a list, GET /v1/<resource>/<key> for one record, and where allowed POST and PATCH.

customers products suppliers quotes orders orderlines contracts resources projects contacts suppliercontacts addresses users timetypes pricelists objects1 objects2 objects3 objects4 times materials

customers — customer

GET /v1/customers, GET /v1/customers/<Nr>, POST /v1/customers, PATCH /v1/customers/<Nr>
Scopes: customers:read, customers:write
Filters: modifiedSince, modifiedBefore, name, category

products — product

GET /v1/products, GET /v1/products/<Nr>, POST /v1/products, PATCH /v1/products/<Nr>
Scopes: products:read, products:write
Filters: modifiedSince, modifiedBefore, name, category

suppliers — supplier

GET /v1/suppliers, GET /v1/suppliers/<Nr>, POST /v1/suppliers, PATCH /v1/suppliers/<Nr>
Scopes: suppliers:read, suppliers:write
Filters: modifiedSince, modifiedBefore, name, category

quotes — quote

GET /v1/quotes, GET /v1/quotes/<Nr>, POST /v1/quotes, PATCH /v1/quotes/<Nr>
Scopes: quotes:read, quotes:write
Filters: modifiedSince, modifiedBefore, status, customerNr

orders — order

GET /v1/orders, GET /v1/orders/<Nr>, POST /v1/orders, PATCH /v1/orders/<Nr>
Scopes: orders:read, orders:write
Filters: modifiedSince, modifiedBefore, status, customerNr, supplierNr

orderlines — order line

GET /v1/orderlines, GET /v1/orderlines/<Id>, PATCH /v1/orderlines/<Id>
Scopes: orderlines:read, orderlines:write
Filters: modifiedSince, modifiedBefore, orderNr, includeZeroQuantity

contracts — contract

GET /v1/contracts, GET /v1/contracts/<Nr>, POST /v1/contracts, PATCH /v1/contracts/<Nr>
Scopes: contracts:read, contracts:write
Filters: modifiedSince, modifiedBefore, status, customerNr

resources — resource

GET /v1/resources, GET /v1/resources/<Nr>, POST /v1/resources, PATCH /v1/resources/<Nr>
Scopes: resources:read, resources:write
Filters: modifiedSince, modifiedBefore, name, category

projects — project

GET /v1/projects, GET /v1/projects/<Nr>, POST /v1/projects, PATCH /v1/projects/<Nr>
Scopes: projects:read, projects:write
Filters: modifiedSince, modifiedBefore, customerNr, owner, status

contacts — contact

GET /v1/contacts, GET /v1/contacts/<Id>, POST /v1/contacts, PATCH /v1/contacts/<Id>
Scopes: contacts:read, contacts:write
Filters: modifiedSince, modifiedBefore, customerNr, name

suppliercontacts — supplier contact

GET /v1/suppliercontacts, GET /v1/suppliercontacts/<Id>, POST /v1/suppliercontacts, PATCH /v1/suppliercontacts/<Id>
Scopes: suppliercontacts:read, suppliercontacts:write
Filters: modifiedSince, modifiedBefore, supplierNr, name

addresses — address

GET /v1/addresses, GET /v1/addresses/<Id>, POST /v1/addresses, PATCH /v1/addresses/<Id>
Scopes: addresses:read, addresses:write
Filters: modifiedSince, modifiedBefore, customerNr, supplierNr, objectNr, level

users — user

GET /v1/users, GET /v1/users/<Sign>
Scopes: users:read, users:write
Filters: modifiedSince, modifiedBefore, name, includePassive, includeArchived

timetypes — time type

GET /v1/timetypes, GET /v1/timetypes/<Name>
Scopes: timetypes:read, timetypes:write
Filters: modifiedSince, modifiedBefore, billable, includeArchived

pricelists — price list

GET /v1/pricelists, GET /v1/pricelists/<Nr>
Scopes: pricelists:read, pricelists:write
Filters: modifiedSince, modifiedBefore, includeArchived

objects1 — object 1

GET /v1/objects1, GET /v1/objects1/<Nr>, POST /v1/objects1, PATCH /v1/objects1/<Nr>
Scopes: objects1:read, objects1:write
Filters: modifiedSince, modifiedBefore, name, category, customerNr

objects2 — object 2

GET /v1/objects2, GET /v1/objects2/<Nr>, POST /v1/objects2, PATCH /v1/objects2/<Nr>
Scopes: objects2:read, objects2:write
Filters: modifiedSince, modifiedBefore, name, category, customerNr

objects3 — object 3

GET /v1/objects3, GET /v1/objects3/<Nr>, POST /v1/objects3, PATCH /v1/objects3/<Nr>
Scopes: objects3:read, objects3:write
Filters: modifiedSince, modifiedBefore, name, category, customerNr

objects4 — object 4

GET /v1/objects4, GET /v1/objects4/<Nr>, POST /v1/objects4, PATCH /v1/objects4/<Nr>
Scopes: objects4:read, objects4:write
Filters: modifiedSince, modifiedBefore, name, category, customerNr

times — time entry

GET /v1/times, GET /v1/times/<Id>, PATCH /v1/times/<Id>
Scopes: times:read, times:write
Filters: modifiedSince, modifiedBefore, ownerNr, ownerType, userSign, invoice

materials — material line

GET /v1/materials, GET /v1/materials/<Id>, PATCH /v1/materials/<Id>
Scopes: materials:read, materials:write
Filters: modifiedSince, modifiedBefore, ownerNr, ownerType, productNr, invoice