Fronteam API

Connect your ERP, CRM or booking system to the Fronteam Logistics calendar. Your system creates, updates and cancels events and gets every change made in Fronteam back (webhooks or polling); anything that would affect assigned crew waits for a manager's decision, and the API never sends a message to employees.

REST + JSONBase URL https://fline.app/api/v1 Version 1.0Enabled per company by the Fronteam admin

Getting started

A manager of the company opens External system connection in Fronteam Logistics, creates a connection and maps your status codes (for example CONFIRMED) to their statuses.
They create a test key (ftk_test_…) and turn the connection on, with Receive changes from their system checked. While the connection is off, every request is rejected (even with a test key); without receiving changes you can only read. With a test key every write is a dry run: the response tells what would happen, and nothing changes.
They send you the access details. When your integration works, they create a live key (ftk_live_…).
To get the changes made in Fronteam, they enter your webhook URL and check Send changes to their system; the signing secret (whsec_…) is shown to them once. Without a webhook you can poll GET /changes. See Changes from Fronteam.

The machine-readable spec: https://fline.app/api/v1/openapi.json (OpenAPI 3.1, no key needed).

Do not send prices in notes or description: the crew assigned to the event can read them.

Authentication

Authorization: Bearer ftk_live_0123…cdef

If your tool cannot send a Bearer header, send X-Api-Key: ftk_live_… instead. A key is shown to the manager only once; Fronteam keeps only a fingerprint of it. A revoked or expired key gets 401 right away.

Keys can be read-only (events:read) or read and write (events:write). Only https://fline.app/api/v1 is accepted - requests sent anywhere else get 403 proxy_required.

A key (and the webhook address) exposes all events with their customer details, so only a manager who may view events and customers can create one; a key that writes also needs permission to edit them.

Requests

Bodies are JSON (Content-Type: application/json), up to 256 KB (batch: 2 MB).
Idempotency: send Idempotency-Key on writes. A retry with the same key and body returns the first answer (Idempotency-Replayed: true) for 24 hours; the same key with a different body is 422 idempotency_key_reused.
Concurrency: every event has an ETag. Send If-Match to update only the version you read; otherwise 409 revision_mismatch. The revision also changes when Fronteam-only fields change - on 409, GET the event and try again.
Rate limits: per connection (default 120 requests per minute; batch up to 100 events). Every answer carries RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset; over the limit you get 429 with Retry-After.
Dates are YYYY-MM-DD and times HH:MM, in the company's time zone; timestamps are UTC (ISO 8601). A field you do not send is not touched; null clears it.
Every answer has X-Request-Id - quote it when you contact support.

Endpoints

Method	Path	What it does
GET	`/me`	The connection, company, key and limits.
GET	`/statuses`	The company's statuses, the code we send for each and the codes you may send.
GET	`/events`	Events page by page: `updated_since`, `from`, `to`, `status`, `include_cancelled`, `include_deleted`, `limit` (up to 200), `cursor`.
GET	`/events/{external_id}`	An event by your id.
GET	`/events/by-fronteam-id/{id}`	An event by our id.
PUT	`/events/{external_id}`	Create (first time) or update (merge). `?dry_run=true` = only tell what would happen.
PATCH	`/events/{external_id}`	Update an event you already linked (404 if not).
DELETE	`/events/{external_id}`	Cancel the event (it is never deleted).
POST	`/events/batch`	Up to 100 upserts / patches / cancels; each item succeeds or fails on its own.
DELETE	`/events/{external_id}/link`	Forget the link between your id and the event (the event stays).
GET	`/changes`	What changed in Fronteam since your `cursor` - the latest change of each event, oldest first.
GET	`/openapi.json`	This API as OpenAPI 3.1.

Your external_id: letters, digits and . _ : ~ -, up to 128 characters. To link an event that already exists in Fronteam, send its fronteam_id in the first PUT (only when the connection covers all company events; otherwise an unlinked event is "not found" for you).

The event object

The same shape in every GET and in every write answer:

{
  "external_id": "ORD-1001",
  "fronteam_id": "7c1f…",
  "revision": 4,
  "name": "Product launch",
  "description": null,
  "notes": "Load-in through gate 3",
  "status": { "code": "CONFIRMED", "name": "Confirmed", "cancelled": false },
  "dates": { "start": "2026-11-05", "end": "2026-11-06" },
  "times": { "setup": "08:00", "start": "18:00", "end": "23:30" },
  "venue": { "name": "Expo Hall 2", "address": "Rokach Blvd 101", "contact_name": "Dana", "contact_phone": "+972501234567" },
  "customer": { "name": "Acme Ltd", "tax_id": "514000000", "phone": null, "email": "ops@acme.com",
                "fronteam_id": "0b9e…" },
  "contact": { "name": "Noa", "phone": "+972521112222", "email": "noa@acme.com" },
  "sales_agent": { "code": "AG-12", "name": "Avi" },
  "schedule": [ { "name": "Setup", "date": "2026-11-05", "start": "08:00", "end": "16:00" } ],
  "sync": { "state": "synced", "pending": [] },
  "deleted": false,
  "updated_at": "2026-10-27T08:15:00Z"
}

customer: matched by tax id, then name, phone and email; a new customer is created only if the company allows it. Existing customers are never changed by the API. schedule is used when the event is created; a later change becomes a note for the manager. sales_agent is the code on the agent's employee card.

Writes and decisions

Status	`result`	Meaning
201	`created`	A new event.
200	`updated` / `unchanged`	Applied, or nothing changed (no new revision).
202	`pending_review` / `partially_applied`	Something waits for a manager - see `held`.

Crew first. Cancelling, restoring or moving the dates of an event with assigned crew - or with invitations, scheduled messages or approval requests about it still pending, or (for cancelling) equipment out on the job - is never applied by the API. You get 202 with the first reason that applies (crew_assigned / pending_invites / scheduled_messages / pending_approvals / equipment_out / conflicts) and the numbers, the manager sees it on the event, and the event updates when they decide - sync.pending shows what still waits. Venue or time changes are applied and the manager is asked whether to notify the crew. The API itself never sends a message to employees.

HTTP/1.1 202 Accepted
{
  "result": "pending_review",
  "applied_fields": [],
  "held": [ { "review_id": "3f2a…", "kind": "cancel_impact", "fields": ["status"], "reason": "crew_assigned",
              "impact": { "assigned": 5 } } ],
  "conflicts": [],
  "warnings": [],
  "event": { "external_id": "ORD-1001", "status": { "code": "CONFIRMED" }, "sync": { "state": "pending_review" } }
}

Both sides changed the same field: by default the value set in Fronteam wins and the conflict is reported to the manager (conflicts); the company can choose "theirs wins" or "ask me" instead.

Direction per field: for each field the company can choose both ways (the default), only from you, only from Fronteam, or not synced. A field that is "only from Fronteam" or "not synced" is not taken from your writes - the response says so in warnings (example below) and the rest of the request is applied; on create, name and dates.start are always taken. A field that is "only from you" or "not synced" is left out of everything we send you (GET, webhooks, /changes) - so a missing field means "not sent", never "cleared". Cancelling (DELETE) always goes through, whatever the direction of status.

"warnings": [ { "code": "field_not_writable", "field": "notes" } ]

Changes from Fronteam

When a manager edits, moves, cancels or deletes a linked event in Fronteam, your system hears about it - by webhook (we call you) or by polling GET /changes (you ask us). A change you made through the API is never sent back to you.

Webhooks

POST https://erp.example.com/fronteam/hook
webhook-id: 6d1c2b0e-…
webhook-timestamp: 1761552900
webhook-signature: v1,K5oZfzN95Z9UVu1EsfQmfVNQhnkZ2pj9o9NDN/H/pI4=

{ "type": "event.updated", "timestamp": "2026-10-27T08:15:00Z",
  "data": { "sequence": 1851, "event": { "external_id": "ORD-1001", "revision": 5, … } } }

`type`	When
`event.created` / `event.updated`	A linked event was created or changed in Fronteam (name, dates, times, venue, status, customer, notes, schedule…).
`event.cancelled` / `event.uncancelled`	Moved to / out of a cancelled status.
`event.deleted` / `event.restored`	Deleted (you get a tombstone with `recoverable_until`) / restored from the recycle bin.
`change.rejected`	Part of your write was not applied: Fronteam kept its own value in a conflict, or a manager declined a change that waited for a decision (`data.held[].decision`). `data.conflicts` / `data.held` as in the write answer, `data.request_id` = your request's `X-Request-Id`. Webhook only (not in `GET /changes`).
`ping`	The manager pressed "Send test".

data.event is always the event's current state, so several quick changes arrive as one delivery. If two deliveries of the same event arrive out of order, keep the one with the higher data.sequence. Treat event.updated for an event you don't know as a create.
Editing a customer card alone doesn't send anything - the event's customer details go out with its next change.
Answer 2xx within 10 seconds. Anything else - including redirects, which are not followed - is retried after 1 min, 5 min, 30 min, 2 h, 6 h, 12 h and 24 h, then dropped (the manager can send it again). webhook-id and the body are the same on every retry: use the id to ignore duplicates. If the event changes while a delivery waits for a retry, that delivery is replaced by a new one (a new webhook-id) with the current state.
Answer 410 Gone to stop the deliveries. After 72 hours of failures the webhook is turned off as well, and the manager is told.
Your URL must be https on port 443 and public (internal addresses are refused). We have no fixed outgoing IP address - verify the signature instead of an IP allow-list.
Which events: only events linked to you, unless the Fronteam admin chose "all company events" - then you also get events you never sent (external_id: null), and that is the only case where event.created arrives (an event you create through the API is already yours).

Checking the signature

We follow Standard Webhooks - you can use their library for your language, or check it yourself:

signature = base64(HMAC-SHA256(key, "{webhook-id}.{webhook-timestamp}.{raw body}"))

where key is the base64-decoded part of your secret after whsec_. While the manager rotates the secret, webhook-signature holds two signatures separated by a space - accept the request if one matches. Reject timestamps more than 5 minutes away.

import crypto from 'node:crypto';

// app.post('/fronteam/hook', express.raw({ type: 'application/json' }), (req, res) => …)
function verifyFronteam(req, secret) {
  const id = req.headers['webhook-id'];
  const ts = Number(req.headers['webhook-timestamp']);
  if (!id || !ts || Math.abs(Date.now() / 1000 - ts) > 300) return false;
  const key = Buffer.from(secret.replace(/^whsec_/, ''), 'base64');
  const expected = crypto.createHmac('sha256', key).update(`${id}.${ts}.${req.body}`).digest('base64');
  return String(req.headers['webhook-signature'] || '').split(' ').some((s) => {
    const [v, sig = ''] = s.split(',');
    return v === 'v1' && sig.length === expected.length &&
           crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected));
  });
}

Polling: `GET /changes`

GET /changes?cursor=1842
{ "changes": [ { "sequence": 1851, "type": "event.cancelled", "occurred_at": "2026-10-27T08:15:00Z",
                 "event": { "external_id": "ORD-1001", … } } ],
  "next_cursor": "1851", "has_more": false }

Keep next_cursor and send it next time (first call - without a cursor). has_more: true - call again right away. Events come in the order their changes were saved, each in its current state; a change saved late comes after what you already got - never skipped. Works only while sending is on (otherwise 403 outbound_disabled). Changes are kept 30 days: a cursor older than that, or from before sending was turned off and on again, gets 410 cursor_expired - read GET /events again and continue without a cursor.

Errors

{ "error": { "code": "validation_failed", "message": "…", "request_id": "…",
             "details": { "errors": [ { "field": "dates.end", "reason": "on or after dates.start, up to 366 days" } ] } } }

Status	Codes
400	`invalid_json` `invalid_request` `invalid_cursor` `unknown_status`
401	`missing_api_key` `invalid_api_key`
403	`insufficient_scope` `integration_disabled` `inbound_disabled` `outbound_disabled` `company_inactive` `ip_not_allowed` `proxy_required`
404 / 405	`route_not_found` `event_not_found` `method_not_allowed`
409	`revision_mismatch` `already_linked` `external_id_conflict` `idempotency_in_progress` `employee_on_option`
410	`event_deleted` `cursor_expired`
413 / 415	`payload_too_large` `unsupported_media_type`
422	`validation_failed` `unknown_field` `idempotency_key_reused` `no_cancel_status`
429	`rate_limited` `too_many_failed_auth`
5xx	`internal_error` `read_only_transaction` `not_implemented` `integrations_paused` `server_busy` `timeout` - retry with the same `Idempotency-Key` (`Retry-After` when given).

Examples

ה-API של Fronteam

חיבור של מערכת ה-ERP, ה-CRM או מערכת-ההזמנות שלכם ליומן של Fronteam Logistics. המערכת שלכם יוצרת, מעדכנת ומבטלת אירועים, ומקבלת בחזרה כל שינוי שנעשה ב-Fronteam (webhook או משיכה); כל שינוי שהיה פוגע בצוות משובץ ממתין להחלטה של מנהל, וה-API לא שולח אף הודעה לעובדים.

REST + JSONכתובת: https://fline.app/api/v1 גרסה 1.0נפתח לכל חברה בנפרד, על-ידי Fronteam

איך מתחילים

מנהל בחברה פותח ב-Fronteam Logistics את חיבור למערכת חיצונית, יוצר חיבור וממפה את קודי-הסטטוס שלכם (למשל CONFIRMED) לסטטוסים שלו.
הוא יוצר מפתח-בדיקה (ftk_test_…) ומפעיל את החיבור, עם ״לקבל שינויים מהמערכת שלהם״ מסומן. כשהחיבור כבוי כל בקשה נדחית (גם במפתח-בדיקה); בלי ״לקבל שינויים״ אפשר רק לקרוא. עם מפתח-בדיקה כל כתיבה היא הדמיה: התשובה אומרת מה היה קורה, ושום דבר לא משתנה.
הוא מעביר לכם את פרטי-הגישה. כשהחיבור עובד - הוא יוצר מפתח אמיתי (ftk_live_…).
כדי לקבל את השינויים שנעשים ב-Fronteam הוא מזין את כתובת-ה-webhook שלכם ומסמן ״לשלוח שינויים למערכת שלהם״; סוד-החתימה (whsec_…) מוצג לו פעם אחת. בלי webhook אפשר למשוך מ-GET /changes. ראו שינויים מ-Fronteam.

המפרט המלא, לכלים: https://fline.app/api/v1/openapi.json (OpenAPI 3.1, בלי מפתח).

לא לשלוח מחירים בשדות notes או description: הצוות המשובץ לאירוע קורא אותם.

הזדהות

Authorization: Bearer ftk_live_0123…cdef

כלי שלא יודע לשלוח Bearer יכול לשלוח X-Api-Key: ftk_live_…. המפתח מוצג למנהל פעם אחת בלבד; Fronteam שומרת רק טביעה שלו. מפתח שבוטל או שפג מקבל 401 מיד.

מפתח יכול להיות לקריאה בלבד (events:read) או לקריאה וכתיבה (events:write). בקשות מתקבלות רק דרך https://fline.app/api/v1 - כל כתובת אחרת מקבלת 403 proxy_required.

מפתח (וגם כתובת ה-webhook) חושף את כל האירועים עם פרטי-הלקוחות, ולכן רק מנהל שרשאי לראות אירועים ולקוחות יכול ליצור אותו; מפתח שכותב צריך גם הרשאה לערוך אותם.

בקשות

הגוף ב-JSON (Content-Type: application/json), עד 256KB (ב-batch: עד 2MB).
כתיבה חוזרת בטוחה: שלחו Idempotency-Key בכל כתיבה. ניסיון חוזר עם אותו מפתח ואותו גוף מחזיר את התשובה הראשונה (Idempotency-Replayed: true) במשך 24 שעות; אותו מפתח עם גוף אחר = 422 idempotency_key_reused.
שני כותבים במקביל: לכל אירוע יש ETag. שלחו If-Match כדי לעדכן רק את הגרסה שקראתם; אחרת 409 revision_mismatch. הגרסה משתנה גם כשמשתנים שדות שקיימים רק ב-Fronteam - ב-409 קוראים את האירוע (GET) ומנסים שוב.
קצב: לכל חיבור (ברירת-מחדל 120 בקשות לדקה; batch עד 100 אירועים). בכל תשובה RateLimit-Limit, RateLimit-Remaining ו-RateLimit-Reset; מעל המכסה - 429 עם Retry-After.
תאריכים YYYY-MM-DD ושעות HH:MM, בשעון של החברה; חותמות-זמן ב-UTC (ISO 8601). שדה שלא שלחתם - לא משתנה; null - מנקה אותו.
בכל תשובה יש X-Request-Id - צרפו אותו כשפונים לתמיכה.

נקודות-הקצה

שיטה	נתיב	מה עושה
GET	`/me`	החיבור, החברה, המפתח והמגבלות.
GET	`/statuses`	הסטטוסים של החברה, הקוד שאנחנו שולחים לכל אחד והקודים שאתם יכולים לשלוח.
GET	`/events`	אירועים בעמודים: `updated_since`, `from`, `to`, `status`, `include_cancelled`, `include_deleted`, `limit` (עד 200), `cursor`.
GET	`/events/{external_id}`	אירוע לפי המזהה שלכם.
GET	`/events/by-fronteam-id/{id}`	אירוע לפי המזהה שלנו.
PUT	`/events/{external_id}`	יצירה (בפעם הראשונה) או עדכון (מיזוג). `?dry_run=true` = רק לומר מה היה קורה.
PATCH	`/events/{external_id}`	עדכון אירוע שכבר מקושר (אחרת 404).
DELETE	`/events/{external_id}`	ביטול האירוע (לעולם לא מחיקה).
POST	`/events/batch`	עד 100 יצירות / עדכונים / ביטולים; כל פריט מצליח או נכשל בנפרד.
DELETE	`/events/{external_id}/link`	ניתוק המזהה שלכם מהאירוע (האירוע נשאר).
GET	`/changes`	מה השתנה ב-Fronteam מאז ה-`cursor` שלכם - השינוי האחרון של כל אירוע, מהישן לחדש.
GET	`/openapi.json`	ה-API כ-OpenAPI 3.1.

ה-external_id שלכם: אותיות לטיניות, ספרות ו-. _ : ~ -, עד 128 תווים. כדי לקשר אירוע שכבר קיים ב-Fronteam - שלחו את ה-fronteam_id שלו ב-PUT הראשון (רק כשהחיבור פתוח לכל אירועי-החברה; אחרת אירוע שלא מקושר "לא קיים" עבורכם).

אובייקט-האירוע

אותו מבנה בכל GET ובכל תשובה לכתיבה (ראו הדוגמה בגרסה האנגלית - שמות-השדות זהים):

name, description, notes · status (קוד, שם, מבוטל) · dates (start, end) · times (setup, start, end) · venue (שם, כתובת, איש-קשר, טלפון).
customer: מותאם לפי ח״פ, ואז שם, טלפון ומייל; לקוח חדש נוצר רק אם החברה מאפשרת. לקוח קיים לא משתנה מה-API לעולם. contact - איש-הקשר של האירוע.
sales_agent - הקוד שעל כרטיס-העובד של הסוכן. schedule - נקלט ביצירת האירוע; שינוי אחר-כך הופך לעדכון למנהל.
sync: synced או pending_review, ו-pending - מה עוד ממתין להחלטה.

כתיבה והחלטות

סטטוס	`result`	משמעות
201	`created`	אירוע חדש.
200	`updated` / `unchanged`	הוחל, או שלא השתנה כלום (בלי גרסה חדשה).
202	`pending_review` / `partially_applied`	משהו ממתין למנהל - ראו `held`.

הצוות קודם. ביטול, החזרה מביטול או הזזת-תאריכים של אירוע שיש בו צוות משובץ - או הזמנות, הודעות מתוזמנות או בקשות-אישור עליו שעוד ממתינות, או (בביטול) ציוד שיצא לעבודה - לא מוחלים מה-API. מקבלים 202 עם הסיבה הראשונה שחלה (crew_assigned / pending_invites / scheduled_messages / pending_approvals / equipment_out / conflicts) והמספרים, המנהל רואה את זה באירוע, והאירוע מתעדכן כשהוא מחליט (sync.pending - מה עוד ממתין). שינוי מקום או שעות - מוחל, והמנהל נשאל אם להודיע לצוות. ה-API עצמו לא שולח אף הודעה לעובדים.

שני הצדדים שינו את אותו שדה: כברירת-מחדל הערך שנקבע ב-Fronteam גובר, וההתנגשות מדווחת למנהל (conflicts); החברה יכולה לבחור "שלכם גובר" או "לשאול אותי".

כיוון לכל שדה: לכל שדה החברה יכולה לבחור בשני הכיוונים (ברירת-המחדל), רק מכם, רק מ-Fronteam, או לא מסונכרן. שדה ש"רק מ-Fronteam" או "לא מסונכרן" לא נלקח מהכתיבה שלכם - התשובה אומרת את זה ב-warnings (דוגמה למטה) ושאר הבקשה מוחל; ביצירה name ו-dates.start נלקחים תמיד. שדה ש"רק מכם" או "לא מסונכרן" לא נכלל בשום דבר שאנחנו שולחים אליכם (GET, webhooks, /changes) - כלומר שדה חסר פירושו "לא נשלח", אף פעם לא "נמחק". ביטול (DELETE) עובר תמיד, בלי קשר לכיוון של status.

"warnings": [ { "code": "field_not_writable", "field": "notes" } ]

שינויים מ-Fronteam

כשמנהל עורך, מזיז, מבטל או מוחק ב-Fronteam אירוע מקושר - המערכת שלכם יודעת על זה: ב-webhook (אנחנו פונים אליכם) או במשיכה מ-GET /changes (אתם שואלים אותנו). שינוי שעשיתם בעצמכם דרך ה-API לא נשלח אליכם בחזרה.

Webhooks

מבנה ההודעה, הכותרות ודוגמה - בגרסה האנגלית (השמות זהים).

`type`	מתי
`event.created` / `event.updated`	אירוע מקושר נוצר או השתנה ב-Fronteam (שם, תאריכים, שעות, מקום, סטטוס, לקוח, הערות, לוח-זמנים…).
`event.cancelled` / `event.uncancelled`	עבר לסטטוס מבוטל / יצא ממנו.
`event.deleted` / `event.restored`	נמחק (מקבלים רשומת-מחיקה - tombstone - עם `recoverable_until`) / שוחזר מסל-המיחזור.
`change.rejected`	חלק ממה ששלחתם לא הוחל: Fronteam שמרה את הערך שלה בהתנגשות, או שמנהל דחה שינוי שחיכה להחלטה (`data.held[].decision`). `data.conflicts` / `data.held` כמו בתשובה לכתיבה, ו-`data.request_id` = ה-`X-Request-Id` של הבקשה שלכם. נשלח רק ב-webhook (לא ב-`GET /changes`).
`ping`	המנהל לחץ ״שלח בדיקה״.

data.event הוא תמיד המצב העדכני של האירוע, כך שכמה שינויים מהירים מגיעים במסירה אחת. שתי מסירות של אותו אירוע שהגיעו בסדר הפוך - שומרים את זו עם ה-data.sequence הגבוה. event.updated על אירוע שלא מוכר לכם - מתייחסים אליו כאל יצירה.
עריכה של כרטיס-לקוח לבדה לא שולחת כלום - פרטי-הלקוח של האירוע יוצאים עם השינוי הבא שלו.
לענות 2xx תוך 10 שניות. כל תשובה אחרת - כולל הפניה (לא עוקבים אחריה) - נשלחת שוב אחרי דקה, 5 דקות, 30 דקות, שעתיים, 6, 12 ו-24 שעות, ואז נעצרת (המנהל יכול לשלוח שוב). ה-webhook-id והגוף זהים בכל הניסיונות - לפי המזהה מזהים כפילות. אם האירוע השתנה בזמן שמסירה מחכה לניסיון חוזר, היא מוחלפת במסירה חדשה (webhook-id חדש) עם המצב העדכני.
410 Gone בתשובה = להפסיק לשלוח. אחרי 72 שעות של כישלונות ה-webhook נכבה גם הוא, והמנהל מקבל הודעה.
הכתובת חייבת להיות https בפורט 443 וציבורית (כתובות פנימיות נדחות). אין לנו כתובת-IP יוצאת קבועה - בודקים את החתימה, לא רשימת-IP.
אילו אירועים: רק אירועים שמקושרים אליכם, אלא אם מנהל ב-Fronteam בחר ״כל אירועי-החברה״ - ואז מגיעים גם אירועים שלא שלחתם (external_id: null), וזה המקרה היחיד שבו מגיע event.created (אירוע שאתם יוצרים דרך ה-API כבר שלכם).

בדיקת החתימה

לפי Standard Webhooks - אפשר להשתמש בספרייה שלהם לשפה שלכם, או לבדוק בעצמכם:

signature = base64(HMAC-SHA256(key, "{webhook-id}.{webhook-timestamp}.{raw body}"))

כש-key הוא החלק שאחרי whsec_ בסוד, אחרי פענוח base64. בזמן החלפת-סוד יש בכותרת webhook-signature שתי חתימות מופרדות ברווח - מספיק שאחת מתאימה. חותמת-זמן רחוקה מ-5 דקות - לדחות. קוד לדוגמה (Node.js) בגרסה האנגלית.

משיכה: `GET /changes`

שומרים את next_cursor ושולחים אותו בפעם הבאה (בקריאה הראשונה - בלי). has_more: true - לקרוא שוב מיד. האירועים מגיעים לפי סדר שמירת השינויים, כל אחד במצבו העדכני; שינוי שנשמר באיחור מגיע אחרי מה שכבר קיבלתם - אף פעם לא מדולג. עובד רק כשהשליחה דלוקה (אחרת 403 outbound_disabled). השינויים נשמרים 30 יום: cursor ישן יותר, או מלפני שהשליחה כובתה והודלקה שוב, מקבל 410 cursor_expired - קוראים שוב את GET /events וממשיכים בלי cursor.

שגיאות

כל שגיאה באותו מבנה:

{ "error": { "code": "…", "message": "…", "request_id": "…", "details": { … } } }

רשימת הקודים המלאה - בטבלה שבגרסה האנגלית ובמפרט. בשגיאת 5xx - ניסיון חוזר עם אותו Idempotency-Key.

Fronteam API

Getting started

Authentication

Requests

Endpoints

The event object

Writes and decisions

Changes from Fronteam

Webhooks

Checking the signature

Polling: GET /changes

Errors

Examples

ה-API של Fronteam

איך מתחילים

הזדהות

בקשות

נקודות-הקצה

אובייקט-האירוע

כתיבה והחלטות

שינויים מ-Fronteam

Webhooks

בדיקת החתימה

משיכה: GET /changes

שגיאות

דוגמאות

Polling: `GET /changes`

משיכה: `GET /changes`