SitterIT Mobigo API — integratörsguide

Läs och skriv i Mobigo över HTTP: uppdrag, kunder, artiklar, offerter, ordrar, avtal, tid, material och dokument.

Kom igång

Du behöver ett clientId och en API-nyckel från den som driftar Mobigo. Nyckeln visas en enda gång, när integrationen skapas.

Första anropet

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

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

/v1/whoami säger vilken integration nyckeln hör till och vad den får göra.

Skapa ett uppdrag med material och tid

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":   "Service av hiss",
           "materials":  [{ "productNr": "A10001", "quantity": 3 }],
           "times":      [{ "timeType": "Administrativ tid", "hours": 2 }]
         }'

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

Svaret ger id på varje skapad rad. Med id:t går raden att uppdatera direkt med PATCH /v1/materials/{id} eller PATCH /v1/times/{id}.

Autentisering

Allt under /v1 kräver Authorization: Bearer <värde>. Värdet är antingen nyckeln eller ett token. Båda ger samma bolag, samma behörigheter och samma IP-spärr.

Token hämtas med 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"}

Hämta ett nytt när expires_in löpt ut, eller när ett anrop svarar 401. Det finns ingen refresh — hämtningen är ett anrop och kostar mindre än att hålla reda på två sorters token.

Var kommer nyckeln ifrån?

Den skapas av den som driftar Mobigo, på servern, med SitterIT.Mobigo.Api keys create. Du kan inte skapa den själv — och det är meningen: nyckeln knyts till ett bolag och till en Mobigo-signatur, och båda är beslut som hör hemma hos kunden.

Be om tre saker:

Säg samtidigt vilka behörigheter du behöver — de sätts när nyckeln skapas och går inte att utöka i efterhand utan en ny nyckel.

Behörigheter

Varje resurs har två: <resurs>:read och <resurs>:write. Saknas behörigheten svarar API:et 403.

Utöver dem gäller Mobigos egna behörigheter för den signatur nyckeln arbetar som. Ett brett scope ger alltså inte mer än vad signaturen får göra i Mobigo.

Uppdrag

POST /v1/tasks tar hela uppdragets skrivbara yta. Bara customerNr är obligatoriskt. Ett utelämnat fält lämnas orört.

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":        "Halvårsservice hiss 3",
           "taskNote":        "Kunden vill ha besked dagen innan.",
           "customerRef":     "Beställning 88214",
           "status":          "Sent",
           "ownerSign":       "AN",
           "userSigns":       ["AN", "PL"],
           "planStartDate":   "2026-09-14",
           "planStopDate":    "2026-09-16",
           "planDateType":    "FromTo",
           "estimatedTime":   6.5,
           "projectNr":       "P-204",
           "priorityName":    "Hög",
           "object1Nr":       "HISS-0031",
           "customT1":        "Serviceavtal",
           "extraFields":     { "Visma_Ordernr.": "VO-4711" },
           "materials":       [{ "productNr": "A10001", "quantity": 3 }],
           "times":           [{ "timeType": "Normaltid", "hours": 4 }]
         }'

Status

Status kan sättas i samma anrop som uppdraget skapas med fältet status, eller i efterhand med POST /v1/tasks/{nr}/status. Båda vägarna går genom Mobigos egna övergångsregler — API:et har inga egna.

Vid skapande sätts statusen sist, efter utförare, extrafält och rader: Mobigos regler läser uppdraget, och de ska läsa det färdiga. Nekar Mobigo rullas hela uppdraget tillbaka, rader och allt, och API:et svarar 422 med skälet.

Svaret på POST /v1/tasks bär alltid status, också när du inte angav någon.

Plandatum och klockslag

Plandatum är ett intervall med en typ i Mobigo, inte ett datum. Bara två av typerna bär klockslag: FromTo och Fixed. Day, Week och Month är datum, och har ingen tid på dygnet.

Utelämnar du planDateType avgör datumen: rena datum ger Day, datum med klockslag ger FromTo.

{ "planStartDate": "2026-09-15T08:00:00",
  "planStopDate":  "2026-09-15T12:00:00" }   → FromTo 08:00–12:00

{ "planStartDate": "2026-09-15" }            → Day

Anger du själv en typ som inte bär tid, och ändå skickar ett klockslag, svarar API:et 422 med FromTo och Fixed i validValues. Tidigare kapades klockslaget tyst, och uppdraget hamnade på hela dygnet utan att något sa ifrån.

Utelämnas planStopDate går plantiden till dygnets slut. Day är en dag: skickar du ett planStopDate längre fram används det inte. Vill du ha ett spann över flera dagar, ange FromTo.

Ändra ett uppdrag

PATCH rör bara de fält du skickar. Resten lämnas som Mobigo har dem.

curl -X PATCH "https://mobigo-api.kundens-server.se/v1/tasks/U039079"      -H "Authorization: Bearer mk_..."      -H "Idempotency-Key: $(uuidgen)"      -H "Content-Type: application/json"      -d '{ "taskText":   "Byt även packningen",
           "planStartDate": "2026-09-15",
           "userSigns":     ["AN", "KJ"],
           "extraFields": { "Visma_Ordernr.": "VO-4712" } }'

userSigns ersätter tilldelningen — den läggs inte till. En utelämnad lista rör inget, [] tömmer, och en utförare som står kvar behåller sin egen status på uppdraget. Ansvarig är ett eget fält, ownerSign.

Svaret är hela uppdraget efter ändringen — samma form som GET /v1/tasks/{nr}. Byter du prislista ser du alltså direkt vad det gjorde med raderna.

Ordrar och offerter

Båda skapas med sina rader i ett anrop. Går någon rad fel rullas hela posten tillbaka — en halv order hos kunden ser ut som en riktig och blir aldrig kompletterad.

En order med rader

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":     "Ringer före leverans",
           "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", … }

Numret kommer ur Mobigos nummerserie. orderDate blir dagens datum om det utelämnas, och artikelns enhet och namn hämtas ur artikelregistret.

Rader på en befintlig order

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

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

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

Ändra en order

PATCH rör bara de fält du skickar. Resten lämnas som Mobigo har dem.

curl -X PATCH "https://mobigo-api.kundens-server.se/v1/orders/B00065" \
     -H "Authorization: Bearer mk_..." \
     -H "Idempotency-Key: order-B00065-lev" \
     -H "Content-Type: application/json" \
     -d '{ "deliveryDate": "2026-09-21",
           "internalNote": "Leverans framflyttad, kunden meddelad" }'

Enskilda rader ändras på sitt id:

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

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

En offert med material och tid

Offerten bär material- och tidrader, som ett uppdrag — inte orderrader.

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

quoteDate blir dagens datum och giltighetstiden 30 dagar om de utelämnas. Hämta tidtypernas namn med GET /v1/timetypes.

Läsa raderna

Material- och tidrader hänger på olika sorters poster. ownerType säger vilken — task, quote, order eller contract. Utelämnas den tillsammans med ownerNr antas ett uppdrag.

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

Varje rad säger själv vad den hänger på, i OwnerNr och OwnerType.

Frånvaro och kalenderbokningar

Semester, sjukdom, VAB, läkarbesök och privat hör inte till något uppdrag. I Mobigo är de kalenderbokningar: tidrader utan ägare. De skapas med POST /v1/times — inte under ett uppdrag.

curl -X POST "https://mobigo-api.kundens-server.se/v1/times" \
     -H "Authorization: Bearer mk_..." \
     -H "Idempotency-Key: franvaro-JV-2026-07" \
     -H "Content-Type: application/json" \
     -d '{
           "timeType":  "Frånvaro / Semester",
           "userSign":  "JV",
           "date":      "2026-07-02T08:00:00",
           "stopDate":  "2026-07-24T17:00:00",
           "hours":     17,
           "spec":      ""
         }'

Svaret är raden, med ownerNr och ownerType som null — det är just det som gör den fristående.

En periodrad, inte en rad per dag

Ange både date och stopDate. Frånvaron blir EN rad: första dagen 08:00 till sista dagen 17:00.

stopDate skrivs rakt av, så en GET på raden ger tillbaka exakt det du skickade. Skickar du en ren heldagsrad — båda värdena på midnatt — gäller Mobigos egen konvention att stoppet ligger dagen efter sista dagen.

"date": "2026-07-02T08:00:00", "stopDate": "2026-07-24T17:00:00"   ← klockslag, bokstavligt
"date": "2026-07-02T00:00:00", "stopDate": "2026-07-25T00:00:00"   ← heldag t.o.m. den 24:e

Tidtypen måste vara en bokningstyp — framåt i tiden

Börjar raden imorgon eller senare måste tidtypen vara markerad som bokningstyp i Mobigo. Samma regel som klienten tillämpar. Idag och bakåt gäller ingen sådan begränsning — det är där man registrerar intern tid i efterhand.

Är den inte det blir svaret 422 med bolagets bokningstidtyper i validValues. Vilka som finns ser du i GET /v1/timetypes, på fältet BookingType.

Ändra och ta bort

PATCH /v1/times/{id} ändrar raden, stopDate inräknat — en förkortad semester rättas alltså via API:et.

Idempotency-Key

Ett anrop kan gå fram utan att svaret gör det. Utan skydd ger omtagningen kunden två identiska uppdrag.

Idempotency-Key är en sträng du väljer per operation. Kommer samma nyckel tillbaka med samma innehåll svarar API:et med det första svaret i stället för att göra om jobbet.

Svaret ekar tillbaka nyckeln och säger om det är ett sparat svar. Ekot finns även på felsvar.

Idempotency-Key: order-4711
Idempotency-Replayed: false     ← anropet utfördes nu
Idempotency-Replayed: true      ← du fick kvittot på ett tidigare anrop

Idempotency-Key: order-4711   → {"nr":"U039075"}
Idempotency-Key: order-4711   → {"nr":"U039075"}   ← samma uppdrag, inget nytt
Idempotency-Key: order-4712   → {"nr":"U039076"}   ← ny order, nytt uppdrag
Idempotency-Key: order-4711 + ändrat innehåll → 409
utan huvudet                                  → 400

Alla skrivande anrop kräver huvudet: POST och PATCH, på alla resurser.

Sidbläddring

Svaret ser likadant ut för alla resurser:

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

limit är förvalt 50 och kapas vid 500. total är null för de resurser Mobigo inte kan räkna.

Markör

Konstant snabb oavsett hur djupt du kommer. Använd den vid synk.

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 är var förra sidan slutade. Är den null finns inget mer att hämta.

Sidnummer

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

Hämta bara det som ändrats

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

Spara Modified från förra körningen och fråga efter allt som ändrats sedan dess.

Kontakter och adresser

Kontaktpersoner och extra adresser är egna poster som hänger på en kund, en leverantör eller ett objekt. De identifieras med Id, inte med ett nummer.

Kontakter på en kund

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

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

Alla kontakter

Utan customerNr listas hela registret. name söker fritext i namnet.

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

Lägga till en kontakt

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

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

Kontakter när kunden skapas

Skicka dem i samma anrop. Avvisas någon kontakt rullas hela kunden tillbaka.

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

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

Numret utelämnades, så Mobigos nummerserie satte det. Svaret innehåller kunden med sitt Nr.

Leverantörskontakter

Samma fält, egen väg: /v1/suppliercontacts med supplierNr.

Adresser

Extra adresser — leverans, faktura, besök. Ägaren måste anges, för adresstabellen är gemensam för kunder, leverantörer och objekt.

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

Extrafält

Kundens egna fält, definierade i deras Mobigo. De heter vad kunden döpt dem till och kommer alltid som strängar.

Vilka fält finns?

Varje resurs beskriver sina extrafält: nyckel, typ, om det går att skriva till och vilka värden ett listfält tillåter.

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

# → { "items": [
#       { "Key": "Avtals_typ", "Name": "Avtals typ", "Category": "Avtal",
#         "Type": "Combo", "Writable": true, "ReadOnly": false, "Computed": false,
#         "Options": ["Grundservice", "Incitamentsavtal", "Jouravtal"] },
#       { "Key": "Startdatum_avtal", "Name": "Startdatum avtal",
#         "Type": "Date", "Writable": true },
#       { "Key": "Region", "Name": "Region",
#         "Type": "Sql", "Writable": false, "Computed": true }
#     ],
#     "count": 59 }

Writable: false betyder att en skrivning avvisas — fältet är antingen skrivskyddat eller beräknat av Mobigo. Options finns bara på listfält.

Samma väg på alla resurser, inklusive uppdrag: GET https://mobigo-api.kundens-server.se/v1/tasks/extra-fields.

Läsa

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": ""
#     }
#   }

Tomma fält kommer med som tom sträng, så du ser vilka fält som finns. Det är också så du får de exakta namnen.

Skriva på en resurs

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" } }'

Skriva på ett uppdrag

Samma objekt, i samma anrop som uppdraget skapas:

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"
           }
         }'

Nyckeln är fältets namn i kundens Mobigo, exakt som det står i ExtraFields när du läser posten. Punkter och understreck ingår i namnet. Värdet är alltid en sträng, även för datum och tal.

Fel du kan få

Register

Värdena som andra anrop kräver. De är kundens egna, så de går inte att lista i förväg. Alla är läsbara — de sätts i Mobigos administration.

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

# → { "items": [
#       { "Name": "Normaltid", "Unit": "tim", "BasePrice": 750,
#         "InternalType": false, "BookingType": false,
#         "SpecOptions": ["Felsökning", "Byte"] },
#       { "Name": "Frånvaro / Semester", "Unit": "dgr", "BasePrice": 0,
#         "InternalType": true, "BookingType": true, "SpecOptions": [] }
#     ] }

BookingType säger att tidtypen duger till en fristående kalenderbokning. Namnet är hela strängen, snedstrecket inräknat: i Mobigo är Frånvaro / Semester mappen Frånvaro och typen Semester, men API:et vill ha den skriven i sin helhet.

Kundens egna fältnamn

Custom1–Custom4 heter något annat hos kunden. /v1/field-names säger vad.

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

# → { "items": [
#       { "DbFieldName": "CustCustom1", "UserFieldName": "Post adress",
#         "ListOnly": false, "Hidden": false },
#       { "DbFieldName": "TaskCustom1", "UserFieldName": "Serviceavtal",
#         "ListOnly": true, "Hidden": false }
#     ] }

DbFieldName är namnet API:et använder. UserFieldName är kundens etikett. Hidden betyder att fältet inte visas i Mobigo.

Position

Mobigo geokodar sina poster själv, mot den karttjänst och de regler kunden satt upp. API:et läser den positionen och kan be Mobigo räkna om den, men geokodar aldrig själv.

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 räknar om positionen först, från uppdragets kund, objekt eller adress. ?force=true gör om det även när en position redan finns.

Latitude och Longitude är null när posten saknar position. Status säger varför: NoAddress, AddressNotFound, AddressInvalid, Pending eller Error.

Fast position

För adresser som inte går att slå upp. En fast position skrivs aldrig över av Mobigos egen geokodning.

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

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

Samma två vägar finns på alla resurser: /v1/customers/10003/location, /v1/objects1/O1-11840/location och så vidare.

Dokument på ett uppdrag

Tre anrop: bifoga, lista och hämta. Listan och innehållet är åtskilda — ett uppdrag kan ha bilagor på tiotals megabyte.

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

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

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

GET /v1/tasks/U039079/documents

{ "items": [ { "Id": 60728, "Name": "arbetsorder.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=arbetsorder.pdf
<filens innehåll>

Länkade dokument och utskriftsmallar

Kind säger vad dokumentet är:

Mobigos egen dokumenthantering gör jobbet i alla fyra fallen. Därför kan Content-Type bli application/pdf även när filnamnet slutar på något annat — typen kommer från innehållet, inte från namnet. Saknar namnet filändelse läggs rätt ändelse på i Content-Disposition.

En länk vars sökväg är otillgänglig från servern ger 422 med besked om det, inte en tom fil.

Felkoder

Alla fel är application/problem+json enligt RFC 9457.

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

Giltiga värden: validValues

Avvisas ett värde — ett tidtypsnamn, en status, ett fältnamn — bär felsvaret listan på vad som duger i fältet validValues.

{ "type": "https://sitterit.se/problems/command_failed",
  "title": "command_failed",
  "status": 422,
  "detail": "Ingen tidtyp som heter \"Taxa 2\". 36 giltiga namn finns i validValues, hela listan i GET /v1/timetypes.",
  "validValues": ["Administrativ tid", "Fastpris", "Service, debiterbar", "…"],
  "requestId": "94cc0d1aa31a44a0" }

Det är en lista, inte en mening att tolka. Namn innehåller komma — Service, debiterbar är en enda tidtyp — och i en kommaseparerad text går de inte att skilja åt. Läs listan, fyll en rullgardin, jämför mot den innan du skickar.

Fältet finns bara när felet handlar om ett avvisat värde och listan är känd. Ett 404 eller 503 bär det inte.

Spårning: X-Request-Id

Varje svar bär X-Request-Id. Felsvar har samma värde i fältet requestId. Ange det i supportärenden.

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

Skickar du ett eget X-Request-Id används det i stället och ekas tillbaka. Tillåtna tecken är bokstäver, siffror och - _ . :, högst 64.

Spår i Mobigo: ändringsloggen

Varje skrivning lägger en rad i Mobigos egen ändringslogg, den som visas på posten i Desktop. Raden bär integrationens signatur och säger via API, så att den går att skilja från det någon gjort för hand.

Skapade tidrad via API, Administrativ tid
Ändrade kund via API

Rader på en post — tid, material, orderrader, kontakter, adresser — loggas på ägaren, alltså på uppdraget, ordern eller kunden. Det är där Desktop lägger sina egna rader, och där någon letar efter vad som hänt.

Det här är Mobigos logg, inte API:ets. API:ets egen revisionslogg över anrop och nycklar beskrivs i drift- och installationsguiden.

Vilket register är det?

Namnen i Swagger är API:ets. Namnen i sista kolumnen är Mobigos egna, så som de står i kundens klient — så att de två fönstren går att hålla bredvid varandra utan att gissa.

Skriva på ett uppdrag

De här skriver inte i ett eget register — de lägger till på uppdraget.

Objektnivåerna 1–4 heter det kunden döpt dem till i sin egen Mobigo — Anläggning, Fastighet, Fordon. GET /v1/field-names ger namnen den installationen använder.

Resurser

Varje resurs har samma form: GET /v1/<resurs> för en lista, GET /v1/<resurs>/<nyckel> för en post, och där det är tillåtet POST och PATCH.

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

customers — kund

GET /v1/customers, GET /v1/customers/<Nr>, POST /v1/customers, PATCH /v1/customers/<Nr>
Behörigheter: customers:read, customers:write
Urval: modifiedSince, modifiedBefore, name, category

products — artikel

GET /v1/products, GET /v1/products/<Nr>, POST /v1/products, PATCH /v1/products/<Nr>
Behörigheter: products:read, products:write
Urval: modifiedSince, modifiedBefore, name, category

suppliers — leverantör

GET /v1/suppliers, GET /v1/suppliers/<Nr>, POST /v1/suppliers, PATCH /v1/suppliers/<Nr>
Behörigheter: suppliers:read, suppliers:write
Urval: modifiedSince, modifiedBefore, name, category

quotes — offert

GET /v1/quotes, GET /v1/quotes/<Nr>, POST /v1/quotes, PATCH /v1/quotes/<Nr>
Behörigheter: quotes:read, quotes:write
Urval: modifiedSince, modifiedBefore, status, customerNr

orders — order

GET /v1/orders, GET /v1/orders/<Nr>, POST /v1/orders, PATCH /v1/orders/<Nr>
Behörigheter: orders:read, orders:write
Urval: modifiedSince, modifiedBefore, status, customerNr, supplierNr

orderlines — orderrad

GET /v1/orderlines, GET /v1/orderlines/<Id>, PATCH /v1/orderlines/<Id>
Behörigheter: orderlines:read, orderlines:write
Urval: modifiedSince, modifiedBefore, orderNr, includeZeroQuantity

contracts — avtal

GET /v1/contracts, GET /v1/contracts/<Nr>, POST /v1/contracts, PATCH /v1/contracts/<Nr>
Behörigheter: contracts:read, contracts:write
Urval: modifiedSince, modifiedBefore, status, customerNr

resources — resurs

GET /v1/resources, GET /v1/resources/<Nr>, POST /v1/resources, PATCH /v1/resources/<Nr>
Behörigheter: resources:read, resources:write
Urval: modifiedSince, modifiedBefore, name, category

projects — projekt

GET /v1/projects, GET /v1/projects/<Nr>, POST /v1/projects, PATCH /v1/projects/<Nr>
Behörigheter: projects:read, projects:write
Urval: modifiedSince, modifiedBefore, customerNr, owner, status

contacts — kontakt

GET /v1/contacts, GET /v1/contacts/<Id>, POST /v1/contacts, PATCH /v1/contacts/<Id>
Behörigheter: contacts:read, contacts:write
Urval: modifiedSince, modifiedBefore, customerNr, name

suppliercontacts — leverantörskontakt

GET /v1/suppliercontacts, GET /v1/suppliercontacts/<Id>, POST /v1/suppliercontacts, PATCH /v1/suppliercontacts/<Id>
Behörigheter: suppliercontacts:read, suppliercontacts:write
Urval: modifiedSince, modifiedBefore, supplierNr, name

addresses — adress

GET /v1/addresses, GET /v1/addresses/<Id>, POST /v1/addresses, PATCH /v1/addresses/<Id>
Behörigheter: addresses:read, addresses:write
Urval: modifiedSince, modifiedBefore, customerNr, supplierNr, objectNr, level

users — användare

GET /v1/users, GET /v1/users/<Sign>
Behörigheter: users:read, users:write
Urval: modifiedSince, modifiedBefore, name, includePassive, includeArchived

timetypes — tidtyp

GET /v1/timetypes, GET /v1/timetypes/<Name>
Behörigheter: timetypes:read, timetypes:write
Urval: modifiedSince, modifiedBefore, billable, includeArchived

pricelists — prislista

GET /v1/pricelists, GET /v1/pricelists/<Nr>
Behörigheter: pricelists:read, pricelists:write
Urval: modifiedSince, modifiedBefore, includeArchived

objects1 — objekt 1

GET /v1/objects1, GET /v1/objects1/<Nr>, POST /v1/objects1, PATCH /v1/objects1/<Nr>
Behörigheter: objects1:read, objects1:write
Urval: modifiedSince, modifiedBefore, name, category, customerNr

objects2 — objekt 2

GET /v1/objects2, GET /v1/objects2/<Nr>, POST /v1/objects2, PATCH /v1/objects2/<Nr>
Behörigheter: objects2:read, objects2:write
Urval: modifiedSince, modifiedBefore, name, category, customerNr

objects3 — objekt 3

GET /v1/objects3, GET /v1/objects3/<Nr>, POST /v1/objects3, PATCH /v1/objects3/<Nr>
Behörigheter: objects3:read, objects3:write
Urval: modifiedSince, modifiedBefore, name, category, customerNr

objects4 — objekt 4

GET /v1/objects4, GET /v1/objects4/<Nr>, POST /v1/objects4, PATCH /v1/objects4/<Nr>
Behörigheter: objects4:read, objects4:write
Urval: modifiedSince, modifiedBefore, name, category, customerNr

times — tidrad

GET /v1/times, GET /v1/times/<Id>, POST /v1/times, PATCH /v1/times/<Id>
Behörigheter: times:read, times:write
Urval: modifiedSince, modifiedBefore, ownerNr, ownerType, userSign, invoice

materials — materialrad

GET /v1/materials, GET /v1/materials/<Id>, PATCH /v1/materials/<Id>
Behörigheter: materials:read, materials:write
Urval: modifiedSince, modifiedBefore, ownerNr, ownerType, productNr, invoice