Beispiele

Zuletzt aktualisiert 17 August 2026

Eine Anfrage, die nur das seit gestern Geänderte holt, daneben weitere durchgerechnete Beispiele

Jede Anfrage auf dieser Seite wurde gegen eine laufende Instanz ausgeführt, bevor sie aufgeschrieben wurde, die Formen funktionieren also nachweislich und sind nicht bloß angenommen. Wo ein Beispiel eine Entität oder ein Feld benennt, ist dieser Name illustrativ: contacts und date_added gibt es überall, während subscriptions und renewal_date für das stehen, wie Ihr Arbeitsbereich seine eigenen nennt. Tauschen Sie die Namen gegen Ihre aus, und die Anfrage bleibt dieselbe.

HOST="https://ihre-subdomain.flexie.io"
KEY="IHR_API_SCHLUESSEL"

Hier anfangen: wonach lässt sich diese Entität filtern

Feldnamen und Operatoren unterscheiden sich von Arbeitsbereich zu Arbeitsbereich, fragen Sie also lieber nach, statt zu raten:

curl "$HOST/api/contacts/list/filters" -H "apikey: $KEY"

Alles Filterbare kommt in einer Liste zurück: die eigenen Felder der Entität, die von Flexie gepflegten wie date_added und die Aktivitätszähler, die Ids der Datensätze, auf die sie zeigt, und die Felder jedes Datensatzes, mit dem sie verknüpft ist.

Die letzte Gruppe ist die, die Sie sich nicht selbst herleiten können, und die gepflegten Felder sind die, von denen die Leute nicht wissen, dass sie sie haben. Bei Kontakten hat diese Liste 168 Einträge, während die eingerichteten Felder allein 24 sind.

{
  "total": 168,
  "fields": [
    {
      "field": "email",
      "label": "Email",
      "type": "string",
      "group": "Contact Fields",
      "related": false,
      "operators": [
        { "operator": "equal",    "value": "single" },
        { "operator": "contains", "value": "single" },
        { "operator": "is_empty", "value": "none"   }
      ]
    },
    {
      "field": {
        "entity": "subscriptions",
        "relation": "manyToOne",
        "through": "subscriptions_id",
        "field": "status"
      },
      "label": "Subscription / Status",
      "type": "string",
      "group": "Related Subscription Fields",
      "related": true,
      "operators": [
        { "operator": "equal",    "value": "single" },
        { "operator": "is_empty", "value": "none"   }
      ]
    }
  ]
}

Drei Dinge, die Sie einem Eintrag entnehmen:

  • field ist das, was Sie senden, unverändert übernommen. Für ein Feld am Datensatz selbst ist das ein Name. Für ein Feld an einem verknüpften Datensatz ist es ein Objekt, das Entität, Beziehung und Feld benennt, und genau dieses Objekt senden Sie.
  • operators ist das, was dieses Feld annimmt, jeweils mit der Form des value, die es will.
  • related sagt, ob das Feld zu diesem Datensatz gehört oder zu einem am anderen Ende einer Beziehung, sodass Sie sie so gruppieren können wie die Oberfläche.

Lesen Sie den zweiten Punkt genau, denn hier wird am häufigsten falsch gelesen. In { "operator": "equal", "value": "single" } ist "single" kein zu sendender Wert. Es benennt die Form, in der Ihr Wert ankommen muss, und single heißt ein einzelner Wert für sich. Der Eintrag oben sagt also: equal nimmt einen Wert, contains nimmt einen Wert und is_empty nimmt keinen.

Es gibt sieben Formen, und das sind alle:

Form Was zu senden ist
single Ein Wert.
{ "field": "email", "operator": "contains", "value": "acme" }
range Zwei Grenzen in einem Array, die untere zuerst.
{ "field": "amount", "operator": "between", "value": [1000, 5000] }
period Ein benannter Zeitraum, damit Sie nie selbst ein Datum ausrechnen.
{ "field": "date_added", "operator": "is", "value": "this_year" }
offset Ein Vorzeichen, eine Zahl und eine Einheit, als drei Zeichenketten.
{ "field": "date_added", "operator": "less_than_now", "value": ["-", "7", "days"] }
list Ein Array von Werten, von denen einer passen muss.
{ "field": "owner_id", "operator": "in", "value": [1, 6] }
polygon Die Punkte einer Fläche. Nur an einem Kartenfeld, wo die Fläche gezeichnet statt getippt wird.
none Gar nichts, lassen Sie value weg.
{ "field": "phone", "operator": "is_empty" }

Eine Regel zu bauen ist damit mechanisch: Nehmen Sie field aus dem Eintrag, wählen Sie einen operator aus dessen Liste und senden Sie einen value in der Form, die dieser Operator genannt hat.

{ "field": "<entry.field>", "operator": "<einer aus entry.operators>", "value":}

Bei benutzerdefinierten Entitäten geht das genauso, und dort zählt es am meisten:

curl "$HOST/api/ce/subscriptions/list/filters" -H "apikey: $KEY"

Alltägliche Filter

Alle bei einer Domain.

curl -X POST "$HOST/api/contacts/search" \
  -H "apikey: $KEY" -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "condition": "AND",
      "rules": [
        { "field": "email", "operator": "contains", "value": "acme.com" }
      ]
    }
  }'
{ "total": "4", "current_page": 1, "total_pages": 1, "contacts": [] }

Nur Adressen, die darauf enden, die strengere Frage und meistens die gemeinte:

{ "field": "email", "operator": "ends_with", "value": "@acme.com" }

Datensätze, denen etwas fehlt.

{ "field": "phone", "operator": "is_empty" }

Eine Zahl über einer Schwelle.

{ "field": "deal_count", "operator": "greater", "value": 0 }

Dieses Jahr hinzugekommen, ohne irgendein Datum auszurechnen. Der Zeitraum wird beim Ausführen der Anfrage bestimmt, dieselbe gespeicherte Anfrage meint also nächsten Monat noch das Richtige:

{ "field": "date_added", "operator": "is", "value": "this_year" }

Zwischen zwei Datumsangaben hinzugekommen, wenn Sie feste Grenzen wollen:

{ "field": "date_added", "operator": "between",
  "value": ["2026-01-01 00:00:00", "2026-12-31 23:59:59"] }

Zwei Bedingungen, davon eine mit Auswahl. Dieses Jahr hinzugekommen, und entweder bei der Domain oder ganz ohne Adresse:

{
  "condition": "AND",
  "rules": [
    { "field": "date_added", "operator": "is", "value": "this_year" },
    {
      "condition": "OR",
      "rules": [
        { "field": "email", "operator": "contains", "value": "acme.com" },
        { "field": "email", "operator": "is_empty" }
      ]
    }
  ]
}

Die Aufgaben, die Integrationen wirklich erledigen

Nur das Geänderte holen, nach Zeitplan. Die Anfrage, die jede Synchronisation braucht. Sortieren Sie nach demselben Feld, nach dem Sie filtern, damit die Seiten beim Durchlaufen stabil bleiben:

curl -X POST "$HOST/api/contacts/search" \
  -H "apikey: $KEY" -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "condition": "AND",
      "rules": [
        { "field": "date_modified", "operator": "is", "value": "last_24_hours" }
      ]
    },
    "orderBy": "date_modified",
    "orderByDir": "ASC",
    "page": 1,
    "limit": 100
  }'

Lassen Sie sie stündlich mit last_hour laufen, nächtlich mit last_24_hours oder nach einer Störung mit last_7_days. Keine Zeitstempel zu speichern und nichts, was an einer Zeitumstellung schiefgehen kann.

Die Datensätze finden, die Ihnen peinlich werden, ohne E-Mail-Adresse oder ohne Telefonnummer:

{
  "condition": "OR",
  "rules": [
    { "field": "email", "operator": "is_empty" },
    { "field": "phone", "operator": "is_empty" }
  ]
}

Die Waisen finden, Kontakte, die an keiner Firma hängen und bei denen nichts läuft:

{
  "condition": "AND",
  "rules": [
    { "field": "account_id", "operator": "is_empty" },
    { "field": "deal_count", "operator": "equal", "value": 0 }
  ]
}

Finden, wem Sie nie geschrieben haben, was meist eine längere Liste ist, als alle erwarten:

{ "field": "last_email_date", "operator": "is_empty" }

Finden, wer still geworden ist, für eine Reaktivierungskampagne. Kontakte, die Sie erreichen können, die seit neunzig Tagen nichts von Ihnen gehört haben, einschließlich derer, denen Sie nie geschrieben haben:

{
  "condition": "AND",
  "rules": [
    { "field": "email", "operator": "is_not_empty" },
    {
      "condition": "OR",
      "rules": [
        { "field": "last_email_date", "operator": "is_empty" },
        { "field": "last_email_date", "operator": "is_not", "value": "last_90_days" }
      ]
    }
  ]
}

Wem Sie noch schreiben dürfen, vor einer Kampagne. Das Abonnement ist kein Feld am Datensatz, es ist die Frage, ob für die Adresse eine Abmeldung vorliegt, deshalb wird es über __unsubscribes gestellt und nimmt keinen Wert:

{ "field": "__unsubscribes", "operator": "is_subscribed" }

Und wer sich abgemeldet hat, aber telefonisch erreichbar ist, also die Anrufliste statt der Verteilerliste:

{
  "condition": "AND",
  "rules": [
    { "field": "__unsubscribes", "operator": "is_not_subscribed" },
    { "field": "phone", "operator": "is_not_empty" }
  ]
}

Die Pipeline dieses Monats, für ein Dashboard oder eine Prognose:

curl -X POST "$HOST/api/deals/search" \
  -H "apikey: $KEY" -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "condition": "AND",
      "rules": [
        { "field": "close_date", "operator": "is", "value": "this_month" },
        { "field": "amount", "operator": "greater", "value": 0 }
      ]
    },
    "orderBy": "close_date",
    "orderByDir": "ASC"
  }'

Deals ohne Besitzer, der Bericht, der Umsatz findet, der durch eine Lücke fällt:

{
  "condition": "AND",
  "rules": [
    { "field": "owner_id", "operator": "is_empty" },
    { "field": "amount", "operator": "greater", "value": 0 }
  ]
}

Deals, die eingeschlafen sind, mit Wert und seit einem Monat unangetastet:

{
  "condition": "AND",
  "rules": [
    { "field": "date_modified", "operator": "is_not", "value": "last_30_days" },
    { "field": "amount", "operator": "greater", "value": 0 }
  ]
}

Über verknüpfte Entitäten hinweg

Hier zahlt sich die Feldliste aus. Sie können Datensätze nach etwas filtern, das am Datensatz am anderen Ende einer Beziehung steht, ohne diese Seite vorher zu holen.

Über die Id, die Sie schon haben. Referenz-Ids kommen in jeder Antwort zurück, das ist also meist eine Id, die Sie gerade gelesen haben:

curl -X POST "$HOST/api/contacts/search" \
  -H "apikey: $KEY" -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "condition": "AND",
      "rules": [ { "field": "account_id", "operator": "equal", "value": 354 } ]
    }
  }'

Über ein Feld des verknüpften Datensatzes. Kontakte, deren Firma soundso heißt, ohne eine einzige Firma zu lesen:

{ "field": { "entity": "account", "field": "name" }, "operator": "contains", "value": "acme" }

Über ein Feld eines verknüpften Datensatzes an einer benutzerdefinierten Entität. Angenommen, Ihr Arbeitsbereich hat eine Entität subscriptions, die an Kontakten hängt, und Sie wollen die Kontakte, deren Abonnement in Verzug geraten ist. Das ist der Fall, den Sie nicht erraten können, fragen Sie also zuerst:

curl "$HOST/api/leads/list/filters" -H "apikey: $KEY"

Suchen Sie nach Einträgen, deren field.entity die Entität ist, um die es Ihnen geht:

{
  "label": "Subscription / Status",
  "related": true,
  "field": {
    "entity": "subscriptions",
    "relation": "manyToOne",
    "through": "subscriptions_id",
    "field": "status"
  }
}

Setzen Sie dieses Objekt dann direkt in eine Regel:

curl -X POST "$HOST/api/leads/search" \
  -H "apikey: $KEY" -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "condition": "AND",
      "rules": [
        {
          "field": { "entity": "subscriptions", "field": "status" },
          "operator": "equal",
          "value": "past_due"
        }
      ]
    }
  }'

entity und field bestimmen es, und bei den meisten Entitäten ist damit alles gesagt.

Ist dieselbe Entität über zwei verschiedene Wege erreichbar, sagen Sie mit through, über welchen, also über das Feld, über das die Beziehung läuft. Ein Deal erreicht eine Firma sowohl über sein eigenes Firmenfeld als auch über die mit ihm verknüpften Firmen, und das sind verschiedene Fragen:

{ "field": { "entity": "account", "through": "account_id", "field": "name" }, "operator": "is_not_empty" }
{ "field": { "entity": "account", "through": "deals_accounts_relation", "field": "name" }, "operator": "is_not_empty" }

Lassen Sie es weg, wo es zwei Wege gibt, wird die Anfrage mit einem 400 abgewiesen, statt über den beantwortet zu werden, der zufällig zuerst passte.

Alles auf einmal. Kontakte, die an einer Firma hängen, kürzlich angefasst wurden und deren Firma eine bestimmte ist oder die Deals haben, neueste zuerst:

curl -X POST "$HOST/api/contacts/search" \
  -H "apikey: $KEY" -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "condition": "AND",
      "rules": [
        { "field": "account_id", "operator": "is_not_empty" },
        { "field": "date_modified", "operator": "is", "value": "last_30_days" },
        {
          "condition": "OR",
          "rules": [
            { "field": { "entity": "account", "field": "name" }, "operator": "contains", "value": "acme" },
            { "field": "deal_count", "operator": "greater", "value": 0 }
          ]
        }
      ]
    },
    "orderBy": "date_modified",
    "orderByDir": "DESC",
    "page": 1,
    "limit": 100
  }'

Benutzerdefinierte Entitäten

Eine benutzerdefinierte Entität verhält sich genau wie eine eingebaute, unter /api/ce/{table_name}/search, mit dem Tabellennamen klein geschrieben, so wie er in Flexie gesetzt ist.

Die Beispiele unten nutzen einen Arbeitsbereich, der Abonnements führt, jedes auf einem Tarif, jedes mit beliebig vielen Zusatzoptionen und jedes zu einem Kontakt gehörig. Setzen Sie Ihre eigenen Entitäten ein, und die Anfragen bleiben unverändert.

Über ihre eigenen Felder. Abonnements, die in Verzug sind und diesen Monat verlängert werden, also die, bei denen heute jemand anrufen muss:

curl -X POST "$HOST/api/ce/subscriptions/search" \
  -H "apikey: $KEY" -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "condition": "AND",
      "rules": [
        { "field": "status", "operator": "equal", "value": "past_due" },
        { "field": "renewal_date", "operator": "is", "value": "this_month" }
      ]
    },
    "orderBy": "renewal_date",
    "orderByDir": "ASC",
    "limit": 100
  }'

Wo viele davon auf eines von etwas anderem zeigen, der Eins-zu-viele-Fall. Jedes Abonnement auf dem Enterprise-Tarif, ohne vorher einen einzigen Tarif nachzuschlagen:

{
  "field": { "entity": "plans", "field": "name" },
  "operator": "equal",
  "value": "Enterprise"
}

Wo sie mit vielen von etwas anderem verknüpft sind, der Viele-zu-viele-Fall. Abonnements mit der Zusatzoption für bevorzugten Support, also die Liste, die Sie brauchen, bevor Sie eine Reaktionszeit zusagen:

curl -X POST "$HOST/api/ce/subscriptions/search" \
  -H "apikey: $KEY" -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "condition": "AND",
      "rules": [
        {
          "field": { "entity": "add_ons", "field": "name" },
          "operator": "equal",
          "value": "Priority Support"
        }
      ]
    }
  }'

Die Regel liest sich in beiden Fällen gleich. Ob die Beziehung eins-zu-viele oder viele-zu-viele ist, ändert, wie Flexie die Tabellen darunter verknüpft, nicht, wie Sie fragen, und relation in der Feldliste sagt Ihnen, welche der beiden Sie vor sich haben.

Von einer benutzerdefinierten Entität eine eingebaute erreichen. Abonnements, deren Kontakt keine E-Mail-Adresse hat, sodass die Verlängerungsmitteilung nirgendwo ankommt:

{ "field": { "entity": "contact", "field": "email" }, "operator": "is_empty" }

Eigene und verknüpfte Felder zusammen. Verlängerungen, die diesen Monat anstehen und entweder auf dem Enterprise-Tarif liegen oder bevorzugten Support haben, damit das Kundenteam weiß, welche es persönlich übernimmt:

curl -X POST "$HOST/api/ce/subscriptions/search" \
  -H "apikey: $KEY" -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "condition": "AND",
      "rules": [
        { "field": "renewal_date", "operator": "is", "value": "this_month" },
        { "field": "status", "operator": "not_equal", "value": "cancelled" },
        {
          "condition": "OR",
          "rules": [
            { "field": { "entity": "plans", "field": "name" }, "operator": "equal", "value": "Enterprise" },
            { "field": { "entity": "add_ons", "field": "name" }, "operator": "equal", "value": "Priority Support" }
          ]
        }
      ]
    },
    "orderBy": "renewal_date",
    "orderByDir": "ASC",
    "limit": 100
  }'

Und von der anderen Seite. Kontakte, deren Abonnement in Verzug geraten ist, gefragt an den Kontakten statt an den Abonnements:

{ "field": { "entity": "subscriptions", "field": "status" }, "operator": "equal", "value": "past_due" }

Fragen Sie wie immer die Entität, was sie erreichen kann:

curl "$HOST/api/ce/subscriptions/list/filters" -H "apikey: $KEY"

Ein ganzes Ergebnis durchlaufen

Halten Sie den Filter fest, lassen Sie die Reihenfolge unverändert, zählen Sie die Seite hoch und hören Sie auf, wenn Sie total_pages erreichen:

curl -X POST "$HOST/api/contacts/search" \
  -H "apikey: $KEY" -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "condition": "AND",
      "rules": [ { "field": "email", "operator": "is_not_empty" } ]
    },
    "orderBy": "id",
    "orderByDir": "ASC",
    "page": 1,
    "limit": 100
  }'

Senden Sie dann denselben Rumpf mit "page": 2. Senden Sie immer ein orderBy, denn ohne garantiert nichts dieselbe Reihenfolge zwischen zwei Anfragen, und ein Datensatz kann auf zwei Seiten auftauchen oder auf keiner. limit ist bei 100 gedeckelt, wie viel Sie auch anfordern.

Anlegen, lesen, aktualisieren, löschen

Ein vollständiger Durchlauf an einem Datensatz.

# anlegen, 201, der ganze Datensatz kommt zurück, samt Id
curl -X POST "$HOST/api/contacts/new" \
  -H "apikey: $KEY" -H "Content-Type: application/json" \
  -d '{
    "first_name": "Ada",
    "last_name": "Lovelace",
    "email": "ada@example.com",
    "phone": "+355 69 000 0000"
  }'
{ "contact": { "id": "9261", "first_name": "Ada", "email": "ada@example.com",
               "date_added": "2026-08-17T11:22:04+02:00" } }
# wieder auslesen
curl "$HOST/api/contacts/9261" -H "apikey: $KEY"

# aktualisieren, nur senden, was sich ändert
curl -X PATCH "$HOST/api/contacts/9261" \
  -H "apikey: $KEY" -H "Content-Type: application/json" \
  -d '{"last_name": "Byron"}'

# eine Notiz anhängen
curl -X POST "$HOST/api/notes/contact/9261" \
  -H "apikey: $KEY" -H "Content-Type: application/json" \
  -d '{"text": "Zurückgerufen, möchte ein Angebot über 40 Plätze."}'

# seine Notizen lesen
curl "$HOST/api/contacts/9261/notes" -H "apikey: $KEY"

# löschen, 204 und ein leerer Rumpf
curl -X DELETE "$HOST/api/contacts/9261" -H "apikey: $KEY"

Über Ihre eigene Referenz arbeiten

Die meisten Integrationen kennen ihre eigenen Bezeichner, nicht die von Flexie. Markieren Sie das Feld an der Entität als eindeutigen Bezeichner, und Sie brauchen nie eine Zuordnungstabelle.

# den Datensatz darüber finden, 404, wenn nichts passt
curl -X POST "$HOST/api/contacts/identify" \
  -H "apikey: $KEY" -H "Content-Type: application/json" \
  -d '{"unique_field": "email", "unique_field_value": "ada@example.com"}'

# ihn aktualisieren, ohne seine Id zu kennen
curl -X PATCH "$HOST/api/contacts/edit" \
  -H "apikey: $KEY" -H "Content-Type: application/json" \
  -d '{"email": "ada@example.com", "company": "Analytical Engines"}'

/edit aktualisiert, es legt nie an. Für „anlegen, falls nicht vorhanden" rufen Sie zuerst /edit auf und weichen bei einem 404 auf /new aus.

Dynamische Endpunkte

Manchmal ist die API das falsche Werkzeug. Wenn ein anderes System nur etwas zu Flexie schieben soll, ist ein dynamischer Endpunkt einfacher: Er ist eine URL, die einen Workflow startet. Was Sie senden, wird zur Nutzlast des Workflows, und der Workflow entscheidet, was zurückkommt. So kann eine einzige Adresse eine Bestellung annehmen, den Kunden nachschlagen, die Datensätze anlegen und mit dem antworten, was der Aufrufer braucht.

Gebaut werden die am Workflow. Die API listet sie auf, sodass eine Integration selbst herausfinden kann, wohin sie ihre Daten senden soll, statt dass jemand eine URL in eine Konfigurationsdatei einträgt:

curl "$HOST/api/dynamic_endpoints" -H "apikey: $KEY"
{
  "total": 2,
  "dynamic_endpoints": [
    {
      "id": 241,
      "name": "Order intake",
      "url": "https://ihre-subdomain.flexie.io/listener/b5f6f5d7…/240a942a…",
      "authentication_required": true,
      "cors_origins": ["https://shop.example.com"],
      "response_type": "data",
      "workflow_id": 95,
      "workflow_name": "Create an order from the shop"
    },
    {
      "id": 445,
      "name": "Stock check",
      "url": "https://ihre-subdomain.flexie.io/listener/5e77569c…/7cfd78ca…",
      "authentication_required": false,
      "cors_origins": null,
      "response_type": "sse",
      "workflow_id": 143,
      "workflow_name": "Answer a stock question"
    }
  ]
}

Lesen Sie den Eintrag, bevor Sie die Adresse aufrufen:

Feld Was es Ihnen sagt
url wohin die Anfrage geht. Behandeln Sie sie wie eine Zugangsberechtigung: Wer sie hat, kann den Workflow ausführen
authentication_required ob die Anfrage ein signiertes JWT mitführen muss, in einem Authorization: Bearer-Header oder einem token-Header. Bei false ist der Besitz der URL die ganze Sicherheit
cors_origins die Ursprünge, von denen aus ein Browser sie aufrufen darf. null heißt, dass Cross-Origin-Aufrufe aus sind, es kann sie also nur ein Server aufrufen. Ein einzelnes * heißt jeder Ursprung
response_type womit sie antwortet: data oder html für einen festen Rumpf, redirect für ein 302, continue, wenn der Workflow die Antwort baut, sse, wenn sie Ereignisse während des Laufs streamt
workflow_id, workflow_name der Workflow hinter der Adresse, damit Sie wissen, was Sie starten

Der JWT-Schlüssel und das Geheimnis werden nie zurückgegeben. Lesen Sie sie in Flexie am Workflow und bewahren Sie sie dort auf, wo Sie Ihre anderen Geheimnisse aufbewahren.

Rufen Sie dann einen auf. Ein öffentlicher Endpunkt braucht nichts außer der Nutzlast:

curl -X POST "https://ihre-subdomain.flexie.io/listener/5e77569c…/7cfd78ca…" \
  -H "Content-Type: application/json" \
  -d '{"sku": "NW-1180", "quantity": 4}'

Ein Endpunkt mit "authentication_required": true braucht das Token dazu:

curl -X POST "https://ihre-subdomain.flexie.io/listener/b5f6f5d7…/240a942a…" \
  -H "Authorization: Bearer IHR_JWT" \
  -H "Content-Type: application/json" \
  -d '{"order_id": "SO-4471", "email": "ada@example.com", "total": 189.90}'

Drei Dinge, die Sie über die Liste wissen sollten:

  • sie blättert wie jede andere Liste, ?limit=25&start=0, und limit ist bei 100 gedeckelt
  • aufgeführt werden nur Endpunkte an einem veröffentlichten Workflow, denn nur die beantworten eine Anfrage. Eine Adresse, die hier fehlt, ist ein Workflow, der nicht veröffentlicht ist
  • sie ist ein GET und sonst nichts. Jedes andere Verb ist ein 405. Endpunkte entstehen am Workflow, wo die Antwort, die sie senden, und die Nutzlast, die sie erwarten, zusammen entworfen werden

Ihr Schlüssel braucht außerdem die Berechtigung, Workflows zu sehen. Ohne sie ist die Liste ein 403, denn diese URLs führen Workflows aus.

Was abgewiesen wird und warum

Eine Regel, die Flexie nicht beantworten kann, wird mit 400 abgewiesen statt ignoriert, denn sie zu ignorieren hieße, mit einem 200 eine andere Frage zu beantworten:

{ "error": { "code": 400, "message": "Invalid filters" } }
  • ein Feld, das nicht in der Filterliste der Entität steht. id ist eines davon
  • ein Operator, den dieses Feld nicht annimmt. Die Feldliste nennt die, die es annimmt
  • eine Regel auf einem Referenzfeld innerhalb einer OR-Gruppe. Die lassen sich nur mit AND kombinieren, setzen Sie sie also in das äußere AND und behalten Sie das OR für den Rest