Klare Koek ↔ Jobfeed — integratiehandleiding

Laatst bijgewerkt: Versie 1.9.1 — 1 september 2026

Deze handleiding beschrijft de huidige, live situatie. De versiehistorie staat als bijlage achterin.

In één zin

Jullie halen onze vacatures op via een REST-API; bij elke wijziging sturen wij een webhook naar het endpoint dat jullie daarvoor instellen, zodat jullie niet hoeven te pollen; en jullie voegen zelf nieuwe klanten bij ons toe.

Eén set endpoints voor alle omgevingen

Dit is het belangrijkste ontwerpprincipe van de integratie:

• Elke omgeving gebruikt exact dezelfde endpoints, met dezelfde URL's en dezelfde query-syntax. Er bestaat geen apart endpoint voor productie, staging of dev.
• Alleen de API-key verschilt per omgeving. De key bepaalt server-side welke omgeving je ziet en beheert; dat is door de client niet te omzeilen. Jullie prod kan dus nooit staging/dev-vacatures zien, en andersom.
• Gevolg: wat jullie op dev of staging testen is byte-voor-byte hetzelfde codepad als productie. Alleen de key wisselt.

Alle endpoints staan op dezelfde base-URL:

https://yxbnxdoirwwgwiugpunj.functions.supabase.co

Daarnaast sturen wíj webhooks naar jullie endpoints (§3).

1. Wat je van ons krijgt

2. Sleutels en omgevingen

Er zijn twee soorten sleutels, beide per omgeving:

De sleutels delen we uitsluitend via een secure kanaal (1Password-links) — nooit via mail of chat. Belandt een sleutel toch ooit in een onveilig kanaal, dan vervangen wij dat paar uit voorzorg en delen we het nieuwe via 1Password; de overige omgevingen blijven dan ongemoeid.

Overgang: de oude gedeelde KK_API_KEY werkt nog en telt als de 360-prod-key, zodat er geen moment is waarop bestaande bronnen onbeheerbaar zijn. Zodra jullie bevestigen dat alle omgevingen via /get-vacancies lezen (§8), trekken wij die oude key in.

SUPABASE_ANON_KEY is niet meer nodig — en per 1 september ingetrokken. De anon-key die jullie in juni kregen werkt niet meer; jullie kunnen hem uit jullie configuratie verwijderen. Vacatures ophalen gaat via /get-vacancies met je gewone API-key (§4). De publieke database-views waar de anon-key toegang toe gaf zijn er alleen nog voor onze eigen website en tonen uitsluitend productie-data; voor de integratie spelen ze geen rol.

3. Webhooks die wij naar jullie sturen

3.1 Aanleveren door Klare Koek — per jobfeed een eigen endpoint

Elke jobfeed (bron) heeft een eigen, optionele webhook_url. Zo kan elke developer/omgeving (lokaal, dev, staging, prod) z'n eigen endpoint ontvangen. Je geeft hem op bij het aanmaken (POST /add-source, §5) en wijzigt hem wanneer je wilt (PATCH /manage-source/<id>, §5b):

{ "webhook_url": "https://staging.klarekoek.nl/jobfeed/webhook" }

Regels:

• https verplicht en de host moet publiek bereikbaar zijn.
• webhook_url op null zetten = terug naar het globale fallback-endpoint (het ene adres dat jullie ons voor productie leveren; bronnen zonder eigen webhook_url gebruiken dat).
• Een wijziging geldt per direct, óók voor events die al klaarstonden maar nog niet geleverd zijn (endpoint wordt op verzend-moment bepaald).
• Het bearer-secret (§3.4) is per omgeving: een event krijgt het secret van de omgeving waar z'n bron in staat. Gevolg: als twee omgevingen hetzelfde endpoint gebruiken, krijgen ze wél twee aparte POSTs (elk met hun eigen token) in plaats van één gebundelde. Er gaat nooit een event verloren.

We sturen alle vier event-types naar het endpoint van de betreffende bron. Type staat in de body. Webhooks gaan gebatched — één POST per endpoint per event-type per pipeline-run, niet per individuele vacature. Uitzondering: source_down wordt per getroffen bron als aparte POST geleverd (de sources-array bevat dan één bron) — vallen er meerdere bronnen uit in één run, dan krijg je dus meerdere source_down-POSTs. Elke body bevat ook een idempotency_key waarmee je dubbele leveringen kunt herkennen (zie §3.5).

3.2 Frequentie

Onze pipeline draait elke dag om 01:00 UTC. Direct daarna sturen wij alle events van die run: per endpoint één POST per event-type dat voorkwam, plus per getroffen bron een aparte POST voor source_down (§3.1). Zijn jullie tijdelijk onbereikbaar, dan parkeren we de events en proberen we de volgende dag opnieuw. Max 10 pogingen per event (zie §3.6).

3.3 Payload-voorbeelden

new event — nieuwe vacatures:

{
  "event": "new",
  "occurred_at": "2026-05-29T01:15:00Z",
  "idempotency_key": "9f2c0b1e…(sha256-hex)",
  "vacancy_ids": [
    "5ce220c0-a9ad-4de7-871c-3630e78f3b5c",
    "c228f56b-01c9-4260-b1c6-caefdceec2f5"
  ],
  "vacancies": [
    { "id": "5ce220c0-a9ad-4de7-871c-3630e78f3b5c",
      "source_id": "ab50c37a-23a4-46de-b823-7c924cf3f062" },
    { "id": "c228f56b-01c9-4260-b1c6-caefdceec2f5",
      "source_id": "29c01d3b-5715-494d-b95b-49fc7c9473dc" }
  ]
}

update event — gewijzigde vacatures:

{
  "event": "update",
  "occurred_at": "2026-05-29T01:15:00Z",
  "idempotency_key": "a1b2c3d4…(sha256-hex)",
  "vacancy_ids": ["a689f51b-c778-4cc8-be77-9b158f6242bd"],
  "vacancies": [
    { "id": "a689f51b-c778-4cc8-be77-9b158f6242bd",
      "source_id": "ab50c37a-23a4-46de-b823-7c924cf3f062" }
  ]
}

close event — gesloten vacatures (verdwenen uit bron):

{
  "event": "close",
  "occurred_at": "2026-05-29T01:15:00Z",
  "idempotency_key": "e5f6a7b8…(sha256-hex)",
  "vacancy_ids": ["13fa266f-6668-4482-919d-0b8206b8e6be"],
  "vacancies": [
    { "id": "13fa266f-6668-4482-919d-0b8206b8e6be",
      "source_id": "29c01d3b-5715-494d-b95b-49fc7c9473dc" }
  ]
}

vacancies naast vacancy_ids. Elke new/update/close-body bevat beide: vacancy_ids (alleen de ID's) en een vacancies-array met per vacature ook het source_id van z'n jobfeed (dezelfde UUID als in de add-source-response, §5). De arrays zijn index-uitgelijnd: vacancies[i].id == vacancy_ids[i], altijd. Een batch op het globale fallback-endpoint kan vacatures van meerdere bronnen bevatten; gebruik dus het source_id per entry, niet één waarde voor de hele batch. Een eigen source-id in de per-bron webhook-URL verwerken (jullie eerdere workaround) mag ook nog steeds, maar is hiermee niet meer nodig.

⚠️ Een vacature die close heeft gehad blijft bij ons in de database staan met active=false. Je kunt de details nog steeds ophalen via /get-vacancies (zie §4). Als de vacature later weer in de bron verschijnt, krijg je opnieuw een new event met hetzelfde ID.

source_down event — bronfeed van een klant kapot:

{
  "event": "source_down",
  "occurred_at": "2026-05-29T01:15:00Z",
  "idempotency_key": "c9d0e1f2…(sha256-hex)",
  "sources": [
    {
      "source_id": "29c01d3b-5715-494d-b95b-49fc7c9473dc",
      "client_name": "Some Pharma BV",
      "url": "https://careers.somepharma.com/feed.xml",
      "old_status": "healthy",
      "new_status": "broken",
      "message": "HTTP 503 bij ophalen URL",
      "locked": false
    }
  ]
}

3.4 Authenticatie — bearer-token verifiëren

Elke POST draagt een vaste header:

Authorization: Bearer <webhook-secret van de omgeving>

Vergelijk die header met het secret en weiger met 401 als hij niet klopt. Gebruik een constant-time vergelijking om timing-aanvallen te voorkomen. Er is geen raw-body, hash of timestamp nodig — een eenvoudige bearer-token dus, geen HMAC.

Welk secret een POST draagt, hangt af van de omgeving van de bron waar het event bij hoort. Een endpoint dat events uit meerdere omgevingen ontvangt, moet dus meerdere secrets accepteren — controleer de header tegen de set secrets die bij dat endpoint hoort. Elke POST bevat events uit precies één omgeving.

Verificatie in Node.js:

const crypto = require("crypto");

function verifyJobfeedAuth(authHeader, secret) {
  const a = Buffer.from(authHeader || "");
  const b = Buffer.from(`Bearer ${secret}`);
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
// Express: if (!verifyJobfeedAuth(req.get("authorization"), SECRET)) return res.sendStatus(401);

Verificatie in Python:

import secrets

def verify_jobfeed_auth(auth_header: str, secret: str) -> bool:
    return secrets.compare_digest(auth_header or "", f"Bearer {secret}")

De check kijkt alleen naar de header, niet naar de body. Je mag de JSON dus gewoon door je normale parser laten afhandelen. Verifieer de token vóór je de body verwerkt.

3.5 Idempotency — dubbele leveringen herkennen

Elke POST draagt een idempotency-key: dezelfde waarde staat in de body (idempotency_key) én in een header:

X-Idempotency-Key: 9f2c0b1e…(sha256-hex)

De key is deterministisch — een sha256 over het event-type plus de gesorteerde ID's. Een re-send van exact dezelfde batch levert dus exact dezelfde key op (alleen de occurred_at-timestamp in de body verschilt per verzending). De vacancies-array telt niet mee in de key: die wordt alleen uit event-type + ID's afgeleid. Batches worden per endpoint samengesteld (§3.1) met disjuncte ID-sets, dus keys zijn ook over meerdere endpoints heen uniek; dedup per omgeving op alleen de key blijft correct.

In zeldzame gevallen kunnen wij een batch twee keer sturen — bijvoorbeeld een time-out waarbij onze kant de levering niet als geslaagd registreerde. Dedup hierop: heb je deze X-Idempotency-Key al verwerkt, antwoord dan 200 en negeer de inhoud. Zo voorkom je dubbele vacatures aan jullie kant.

Bewaar verwerkte keys daarbij een beperkte tijd — een paar weken is ruim voldoende, want een re-send komt binnen dagen (§3.6). De key bevat bewust geen datum: een legitieme latere levering die toevallig exact dezelfde ID-set heeft (bijvoorbeeld een heropende vacature, §3.3) krijgt dezelfde key en moet niet op een maandenoude dedup-entry stranden.

3.6 Response

Stuur HTTP 200–299 bij succes — geef ook een 2xx bij een al-geziene X-Idempotency-Key (zie §3.5). Bij 400+ markeren wij de batch als gefaald en proberen we het de volgende run opnieuw. Binnen één leverronde proberen we tot 4× met korte tussenpozen (met dezelfde X-Idempotency-Key); zo'n ronde telt als één van de max 10 pogingen (§3.2). Wij volgen geen redirects: jullie endpoint moet terminal zijn — een 3xx behandelen wij als leveringsfout. Na 10 mislukte pogingen zetten wij het event stil; wij krijgen daarvan een interne alert en nemen contact op.

4. Vacature-data ophalen (REST)

Vacatures haal je op via /get-vacancies, met de API-key van de omgeving waarvoor je leest (§2). Zoals overal geldt: zelfde endpoint voor alle omgevingen, de key bepaalt wat je ziet.

GET https://yxbnxdoirwwgwiugpunj.functions.supabase.co/get-vacancies
Headers: Authorization: Bearer <API-key van jullie omgeving>

De query-syntax is PostgREST:

# Eén vacature op basis van een webhook-ID
curl "https://yxbnxdoirwwgwiugpunj.functions.supabase.co/get-vacancies?id=eq.<UUID>" \
  -H "Authorization: Bearer <API-key>"

# Alleen actieve vacatures, compacte payload
curl "https://yxbnxdoirwwgwiugpunj.functions.supabase.co/get-vacancies?active=eq.true&select=id,title,source_id" \
  -H "Authorization: Bearer <API-key>"

Spelregels:

• Standaard krijg je álle pharma-relevante vacatures van je omgeving, inclusief gesloten (mét closed_at). Wil je alleen actieve, voeg active=eq.true toe.
• select=, order=, limit=/offset= en alle kolomfilters (eq./gte./in./…) werken zoals bij PostgREST. Max 1000 rijen per response — pagineer met limit/offset + een vaste order=id. Stuur Prefer: count=exact mee om het totaal in de Content-Range-header te krijgen.
• Een ?environment=…-parameter wordt geweigerd met 400 (de omgeving ligt vast in je key), net als select= met resource-embedding (haakjes) en de parameters apikey, on_conflict en columns. Verder gedraagt het endpoint zich in de query-syntax als PostgREST; van de request-headers gaat alleen Prefer: count=… mee — pagineren doe je dus met limit/offset, niet met een Range-header.
• Een id uit een andere omgeving opvragen geeft géén 404 maar een lege array [] — PostgREST-semantiek: de rij valt buiten je scope. Behandel [] dus niet als fout.
• Het leespad is strikt alleen-lezen en levert uitsluitend de gepubliceerde feed-kolommen; schrijven kan niet en onze ruwe tabellen zijn via dit endpoint niet bereikbaar.
• Zelfde statuscodes als de andere endpoints: 401 (key), 429 (max 20 requests/min — een volledige sync past ruim binnen 1-2 requests), 400 (ongeldige query), 405 (iets anders dan GET) en 500 (interne fout).

Belangrijkste velden

Lege velden komen als null of een lege string. Op jullie kant tonen jullie ze niet — wij garanderen alleen wat de bron aanlevert.

De feed bevat daarnaast een paar velden voor onze eigen site (science_parks, science_park_names); die mag je negeren.

Voor een volledige veld-lijst: GET .../get-vacancies?limit=1 — dat is de bron van waarheid.

Waardelijsten — wij volgen die van jullie

Onze AI mag alléén waarden toekennen die op dat moment in jullie filters-API staan. Concreet:

• Wij lezen elke nacht https://get360pharma.com/api/v1/vacancy-filters en gebruiken experiences, educations, types_of_employment, functions (de groepen → onze category) en de geneste items (→ onze function_areas).
• Voegen jullie een filter toe, dan kennen wij het de volgende nacht toe. Er hoeft bij ons niets aangepast of uitgerold te worden.
• Hernoemen jullie een filter, dan volgt de naam automatisch en blijft het id gelijk; bestaande vacatures houden hun koppeling.
• Verdwijnt een filter, dan stoppen wij het toe te kennen, maar behouden bestaande vacatures hun waarde en id. Wij krijgen daar een melding van.
• hours_type (Voltijd/Deeltijd) heeft geen tegenhanger in jullie filters-API en houdt daarom geen id.

5. Nieuwe klant toevoegen (REST)

POST https://yxbnxdoirwwgwiugpunj.functions.supabase.co/add-source
Headers:
  Authorization: Bearer <API-key van jullie omgeving>
  Content-Type: application/json

Body:
{
  "client_name": "Some Pharma BV",
  "url": "https://careers.somepharma.com/feed.xml",
  "country": "NL",                           // optioneel, default NL (volledige namen worden naar ISO genormaliseerd)
  "source_type": "xml_feed",                 // optioneel, auto-detected
  "min_description_chars": 50,               // optioneel, per-klant tunable
  "webhook_url": "https://dev.klarekoek.nl/jobfeed/webhook"  // optioneel, per-bron endpoint (§3.1)
}

Mogelijke responses:

• 201 Created — bron actief, eerstvolgende run (dagelijks 01:00 UTC) verwerkt 'm
• 400 validation — verplicht veld mist, foute URL of ongeldige webhook_url
• 401 unauthorized — verkeerde of geen API-key
• 409 duplicate — de URL is al in gebruik binnen jullie omgeving door een actieve of gepauzeerde bron; de body bevat normaliter het bestaande source_id + active (en bij een gepauzeerde bron een hint: heractiveer met PATCH /manage-source/<id>, §5b). Een verwijderde bron blokkeert niet, en dezelfde URL in een ándere omgeving ook niet — dit 409 zie je dus alleen bij een échte dubbele.
• 422 probe_failed — URL niet bereikbaar of geen geldige feed
• 429 rate_limited — max 20 requests per minuut

Voorbeeldrespons (201):

{
  "source_id": "ab50c37a-23a4-46de-b823-7c924cf3f062",
  "client_name": "Some Pharma BV",
  "source_type": "xml_feed",
  "url": "https://careers.somepharma.com/feed.xml",
  "country": "NL",
  "min_description_chars": null,
  "webhook_url": "https://dev.klarekoek.nl/jobfeed/webhook",
  "environment": "dev",
  "candidate_count": 1952,
  "message": "Bron actief — eerstvolgende pipeline-run (dagelijks 01:00 UTC) verwerkt ~1952 vacatures"
}

⚠️ candidate_count is het totale aantal in de feed. Onze pipeline filtert per country — voor een NL-klant blijven typisch minder vacatures over. Voor een nauwkeuriger preview zie §6.

Default-landen

• Niet meegegeven → NL
• Pilot dekt Nederland en België — voor country: "BE" werkt alles direct
• Land wordt genormaliseerd naar ISO 3166-1 alpha-2; volledige namen en lokale varianten worden herkend voor NL, BE en DE (Netherlands, België, Deutschland, …). Andere waarden slaan we ongewijzigd op. Het pipeline-filter matcht beide vormen.

5b. Klant wijzigen of uitzetten (REST)

Gebruik het source_id uit de add-source-response (of uit de 409-body).

Omgevings-scope: een key beheert alléén bronnen die met een key van dezelfde omgeving zijn aangemaakt. Een source_id uit een andere omgeving geeft dezelfde 404 als een onbekend id.

Wijzigen

PATCH https://yxbnxdoirwwgwiugpunj.functions.supabase.co/manage-source/<source_id>
Headers:
  Authorization: Bearer <API-key van jullie omgeving>
  Content-Type: application/json

Body (alle velden optioneel, minstens één):
{
  "client_name": "Some Pharma B.V.",
  "url": "https://careers.somepharma.com/feed-v2.xml",  // wordt opnieuw geprobed
  "source_type": "xml_feed",
  "country": "BE",
  "min_description_chars": 80,     // null = terug naar onze default
  "webhook_url": "https://staging.klarekoek.nl/jobfeed/webhook",  // null = globale fallback
  "active": true                   // true = gedeactiveerde bron heractiveren
}

Bijzonderheden:

• Een nieuwe url wordt gecanonicaliseerd en opnieuw geprobed — 422 als hij niet bereikbaar/herkenbaar is, 409 als een andere bron in dezelfde omgeving hem al gebruikt. Zonder expliciete source_type volgt het type de detectie van de nieuwe feed.
• Een gewijzigde webhook_url geldt per direct, óók voor events die nog in onze wachtrij staan (§3.1).
• Heractiveren (active: true) kan 409 geven als een nieuwe bron de URL inmiddels heeft geclaimd binnen jullie omgeving (de URL komt bij een DELETE immers per direct vrij).

Uitzetten (soft-delete)

DELETE https://yxbnxdoirwwgwiugpunj.functions.supabase.co/manage-source/<source_id>
Headers:
  Authorization: Bearer <API-key van jullie omgeving>

• De bron gaat per direct op inactief; er wordt niets weggegooid.
• De feed-URL is per direct weer vrij binnen jullie omgeving — dezelfde URL opnieuw aanmaken via POST /add-source kan dus meteen. Dat is dan wél een nieuwe bron: de vacatures krijgen nieuwe id's, en de oude id's krijgen diezelfde nacht hun close-event (beide batches kunnen in dezelfde nacht binnenkomen).
• De eerstvolgende nachtelijke run sluit alle openstaande vacatures van de bron en stuurt jullie de bijbehorende close-webhook — daarna is de feed leeg voor die klant.
• Idempotent: een tweede DELETE geeft opnieuw 200.
• Heractiveren kan altijd: PATCH met {"active": true} (tenzij de URL intussen opnieuw is uitgegeven — dan 409). Keert een vacature terug in de bron, dan krijg je opnieuw een new-event met hetzelfde ID (§3.3).

Responses (beide methoden)

• 200 OK — body bevat de actuele bron + message
• 400 validation — ongeldig veld, geen uuid in het pad, of lege PATCH-body
• 401 unauthorized / 404 not_found / 409 duplicate / 422 probe_failed
• 429 rate_limited — max 20 requests per minuut

6. Preview tijdens setup (REST)

Vóórdat een klant in onze sources staat, kunnen jullie tonen hoeveel vacatures er in de feed zitten.

GET https://yxbnxdoirwwgwiugpunj.functions.supabase.co/preview?url=<URL-encoded>
Headers:
  Authorization: Bearer <API-key van jullie omgeving>

Respons (200):

{
  "url": "https://careers.somepharma.com/feed.xml",
  "source_type": "xml_feed",
  "candidate_count": 1952,
  "message": "1952 vacatures gevonden in xml_feed (root: <source>)"
}

Mogelijke errors: 400 (ongeldige URL), 401 (auth), 422 (URL is geen herkende feed of niet bereikbaar), 429 (max 20 requests per minuut), 500 (interne fout).

7. Bron-types die wij ondersteunen

HTML-scraping is niet actief (uitgezet per 26 mei 2026). Jullie kunnen alleen klanten toevoegen die een feed of sitemap publiceren. Bij twijfel: gebruik eerst /preview om te checken of de URL detecteerbaar is.

8. Wat moeten jullie ons aanleveren?

• Globale fallback webhook-URL voor productie (per-omgeving endpoints regelen jullie zelf per jobfeed via webhook_url, §3.1/§5b)
• Lijst extra landen naast NL/BE die jullie willen ondersteunen
• Bevestiging dat de bearer-token-check bij jullie werkt (§3.4)
• Bevestiging dat alle omgevingen vacatures ophalen via /get-vacancies (§4) — daarna trekken wij de oude gedeelde KK_API_KEY en de anon-leesroute voor jullie definitief in
• Bevestiging dat type_of_contract hetzelfde is als type_of_employment. Wij leveren het als alias met dezelfde waarde en hetzelfde id. Bedoelen jullie er iets anders mee, laat het weten — dan bouwen we het als eigen veld.

9. Open punten / known issues

• Twee filters met dezelfde naam krijgen geen id. Als jullie binnen één filtergroep twee keer dezelfde naam gebruiken, kunnen wij niet kiezen en blijft het _id-veld null (de naam zelf komt gewoon door). Op jullie development-instantie komt Regulatory Affairs bijvoorbeeld voor onder zowel R&D als Regulatory Affairs (stand: augustus 2026). Wij krijgen daar een melding van.
• Sectoren. Wij zien de nieuwe sectors-velden op development en onze code verwerkt ze al. Zolang een filternaam binnen z'n groep uniek blijft, verandert er voor de koppeling niets. Gaan jullie per sector afwijkende filters met dezelfde naam gebruiken, laat het dan even weten — dan breiden wij de koppeling met een sector-dimensie uit.
• Wij lezen productie, niet development. De development-instantie heeft afwijkende, oudere content (10 i.p.v. 12 experiences, 3 i.p.v. 6 types_of_employment). Zodra de nieuwe filters-API-structuur (met sectors) op jullie productie live staat, verandert er voor ons niets — we lezen productie al.
• Opschoonverzoek filternamen. Een paar filternamen hebben een spatie aan het eind (Business Development, Chemical, Quality, Equipment Validation, Temporary to Permanent) en twee gebruiken een typografische apostrof (Bachelor’s Degree (HBO, WO), Master’s Degree (WO)). Wij normaliseren dat weg, dus het werkt gewoon — maar aan de bron opschonen is netter.
• Preview-count is wereldwijd, ingestie is per-country. Voor een klant met country=Netherlands ziet Klare Koek in de preview het hele feed-totaal, maar in de feed komt alleen NL-deel terecht. Te verbeteren met ?country= param op de preview-call — open punt.
• Smart-close lag. Een vacature die uit een gezonde bronfeed verdwijnt krijgt 1 dag later een close-event. Voor bronnen die als "wankel" (degraded/broken) bekend staan houden we een buffer van 3 dagen aan om mass-closure bij storingen te voorkomen.
• Bestaande vacatures opnieuw exporteren. Bij de eerste koppeling met Klare Koek krijgen jullie geen "bulk-export" automatisch. Optie: één keer handmatig /get-vacancies leegpagineren voor de initiële vulling (inclusief source_id per rij).
• Update-detectie heeft een 2-daags venster. Een URL die wij <2 dagen geleden nog in de feed zagen wordt niet opnieuw geïnhaleerd; een gewijzigde vacaturetekst levert dus pas een update-event zodra de URL buiten dat venster valt. In de praktijk: updates komen door, maar niet altijd de volgende ochtend al.

10. Test-feed

Voor jullie implementatietest hosten wij een kleine, door ons bestuurbare test-jobfeed met 3 fictieve pharma-vacatures:

https://yxbnxdoirwwgwiugpunj.supabase.co/storage/v1/object/public/testfeeds/kk/feed.xml

Zo gebruik je hem:

1. GET /preview?url=<encoded feed-url> → hoort candidate_count: 3 te geven.
2. POST /add-source met deze URL, client_name: "KK Testfeed" en jullie eigen webhook_url (bv. een dev-tunnel) → 201 met source_id.
3. Wij draaien de pipeline on demand tijdens jullie testvenster en muteren de feed in stappen, zodat jullie achtereenvolgens een new-, update-, close- en desgewenst source_down-batch ontvangen.
4. Test PATCH/DELETE op ditzelfde source_id (§5b) — inclusief het wisselen van webhook_url tussen jullie omgevingen.
5. Na afloop ruimen wij de testbron en -vacatures op.

Plan het testvenster even met ons in — dan draaien wij de runs en de feed-mutaties op afroep, en kijken we live mee met de logs.

Bijlage — versiehistorie

Eén regel per versie; de details staan verwerkt in de hoofdtekst.

• 1.9.1 (1 sep 2026) — de in juni gedeelde SUPABASE_ANON_KEY is ingetrokken (vacatures ophalen gaat via /get-vacancies, §4).
• 1.9 (17 aug 2026) — geen inhoudelijke wijzigingen; document herschreven als beschrijving van de huidige situatie.
• 1.8 (17 aug 2026) — leespad per omgeving geïsoleerd via /get-vacancies (bestaande keys, geen nieuwe); source_id in elke vacature én in de webhook-bodies (vacancies-array); oude publieke views alleen nog voor onze eigen site (alleen productie-data).
• 1.7 (aug 2026) — filters-API wordt nachtelijk gevolgd (jullie lijst is leidend); alle filter-id's in de feed; jullie eigen sleutelnamen als extra velden; 7 API-keys met jullie labels; webhook-secret per omgeving.
• 1.6 (juli 2026) — secties in Markdown; eerste filter-id-kolommen; API-key per omgeving; feed-URL per omgeving en vrij na verwijderen.
• 1.5 (juli 2026) — per-jobfeed webhook_url; PATCH/DELETE op /manage-source; alle veldnamen Engels; test-feed.
• 1.4 en eerder — basisintegratie: webhooks met bearer-token, leespad, /add-source, /preview.