Lumenbase API-referens

1. Steg 1

   Skapa en nyckel

   Ge bara de scopes som integrationen använder. Nyckeln visas en gång.

   InställningarFöretagsinställningarAPI
3. Steg 2

   Skicka ett anrop

   Lägg nyckeln i Authorization-huvudet i varje anrop.

   Bearer lmb_…
5. Steg 3

   Läs svarskuvertet

   Kontrollera success, läs data och logga meta.request_id för supporten.

   meta.request_id

https://api.lumenbase.io/functions/v1

Authorization: Bearer <YOUR_API_KEY>
Content-Type: application/json

Valfria huvuden

• X-Idempotency-Key Gör ett omförsök av en import säkert. Se Idempotens.
• X-Request-Id Ditt eget spårnings-id, som returneras i meta.request_id.

Varje svar

{
  "success": true,
  "data": { ... },
  "meta": {
    "request_id": "req_...",
    "api_version": "1",
    "timestamp": "..."
  }
}

{
  "success": false,
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "...",
    "details": { "field": "..." }
  },
  "meta": { ... }
}

Varje anrop bär en API-nyckel för arbetsytan som Bearer-token. Ingen annan form accepteras.

Authorization: Bearer lmb_0f2a...

• En nyckel är lmb_ följt av 64 hexadecimala tecken.
• Nycklar lagras hashade. Vi kan inte visa en igen, så spara den när du skapar den.
• Återkallelsen gäller från nästa anrop. Skapa ersättaren först, så blir rotationen utan avbrott.
• En nyckel hör till en arbetsyta. Den kan bara läsa poster i den arbetsytan, och bara länka till dem.
• Poster som en nyckel skapar tillskrivs personen som skapade nyckeln, eller en admin i arbetsytan om personen har lämnat.

Varje nyckel har ett eller flera scopes. Ge bara det som integrationen använder.

contact_ingest och activity_ingest är äldre namn som fortfarande fungerar. Vart och ett ger läs- och skrivåtkomst till kontakter respektive aktiviteter.

Alla listendpoints tar de här frågeparametrarna.

{
  "success": true,
  "data": {
    "items": [ ... ],
    "pagination": { "page": 1, "per_page": 25, "total": 142, "total_pages": 6 }
  },
  "meta": { ... }
}

Förgrena på error.code, inte på meddelandet. Meddelanden är skrivna för människor och kan ändras; koder är en del av avtalet.

Gränserna gäller per arbetsyta och räknas i fönster på en minut. Varje resurs har sin egen hink.

• Alla resurser: 100 anrop per minut. Batchimport förbrukar kontakternas hink.
• Kontakter: dessutom 10 000 anrop per dygn.
• Aktiviteter: dessutom 50 000 anrop per dygn.
• Ett batchanrop räknas en gång mot dygnstaket, oavsett hur många kontakter det bär.

Lyckade svar bär

• X-RateLimit-LimitTillåtna anrop per minut i den här hinken.
• X-RateLimit-RemainingAnrop kvar den här minuten.
• X-RateLimit-ResetNär minuten nollställs, i Unix-sekunder.
• X-DailyLimit-RemainingAnrop kvar i dag. Endast kontakter och aktiviteter.
• X-DailyLimit-ResetNär dygnet nollställs, i Unix-sekunder. Endast kontakter och aktiviteter.
• Retry-AfterVid en 429, väntetiden i sekunder.

Skicka X-Idempotency-Key så att ett omförsök efter en timeout inte kan skapa en dubblett. Samma nyckel inom 24 timmar ger tillbaka det ursprungliga resultatet i stället för att skriva igen.

X-Idempotency-Key: 7d3f9c1e-2b84-4a17-9f0d-6c5e8a2b1d34

Använd 8 till 128 tecken, unikt per operation. En UUID fungerar. En nyckel utanför den längden ignoreras, den avvisas inte.

Nycklar gäller per arbetsyta och resurs och varar i 24 timmar. En upprepning svarar 200 med det första svaret. Idempotency-Key fungerar som alias.

• Kontakter matchas på e-post, sedan telefon.
• Företag matchas på domän (hämtas från en jobbadress när ingen skickas), sedan webbplats, sedan namn.
• En aktivitet utan deal_id kopplas till företagets senaste öppna affär.
• En koppling mappar dina egna fältnamn till de här fälten för importendpointarna. Kapslad JSON använder punktnotation, till exempel user.profile.email.

Versionen ligger i sökvägen och upprepas i varje svar som meta.api_version och huvudet X-API-Version.

Nya fält kan dyka upp i ett svar när som helst och räknas inte som en brytande ändring. Tolka defensivt och ignorera fält du inte känner igen, i stället för att validera mot en exakt form.

En brytande ändring innebär ett nytt sökvägsprefix. Det befintliga fortsätter fungera genom processen nedan.

Programversionen som visas på andra ställen i produkten är ett releasedatum, inte en API-version. De två rör sig oberoende av varandra.

När en endpoint ska fasas ut säger den det i sina egna svar innan den slutar fungera.

En endpoint under utfasning returnerar

• Deprecationtrue
• Sunsetdatumet då den slutar svara, som ett HTTP-datum.
• Linkersättaren, med rel som pekar på efterföljande version.

Sunset-datumet ligger minst sex månader efter att utfasningen aviserats. När det passerats returnerar endpointen 410 Gone och namnger sin ersättare.

Under utfasning nu

• POST /public-contactsPOST /v1-public-contactsSunset 26 november 2026
• POST /public-activitiesPOST /v1-public-activitiesSunset 31 mars 2027

Logga dessa huvuden. De är den tidigaste varning du får, och de kommer på svar som i övrigt lyckas.

Hela avtalet publiceras som ett OpenAPI 3.1-dokument. Importera det i Postman eller Insomnia, generera en klient, eller jämför det mellan releaser för att se exakt vad som ändrats.

https://lumenbase.io/api/openapi.json

curl -s https://lumenbase.io/api/openapi.json -o lumenbase-openapi.json

1. 1Ge varje integration en egen nyckel, så kan du återkalla en utan att bryta resten.
2. 2Skicka en e-postadress med varje kontakt. Det är den mest tillförlitliga matchningen.
3. 3Skicka X-Idempotency-Key när du gör om en import.
4. 4Läs in kontakter i bulk via batch-endpointen.
5. 5Skicka webbformulär till POST /v1-public-inbound-submissions med en nyckel som bara har inbound:submit. En läckt nyckel kan då bara skicka formulärsvar.
6. 6Håll koll på X-RateLimit-Remaining, och vänta Retry-After vid en 429.
7. 7Logga meta.request_id från varje svar. Supporten hittar ditt anrop med det.

Beteende som inte stämmer med vad resten av den här sidan får dig att förvänta dig. Det står här eftersom det är sämre att upptäcka det i drift.

• Två anrop med samma X-Idempotency-Key som skickas i samma ögonblick kan båda skriva.
• activity_id i svaret från en kontaktimport kan inte hämtas via endpointarna för aktiviteter.
• En importerad aktivitet behåller sin typ bara i importloggen. På tidslinjen är typen note.
• Anrop som avvisas av minutgränsen räknas ändå mot dygnstaket.
• Inbound-formulärsvar delar X-Idempotency-Key med kontakterna. En nyckel som redan använts på POST /v1-public-contacts ger samma svar igen. Skicka external_id i stället, det sparas per formulär.