Endringer

EndretIngen betalingsmur på et nettsted

POST /api/v1/posts og PATCH /api/v1/posts/{id} svarer 409 paywall-on-site når et nettsted sender paid: true, og ingenting blir skrevet. paid: false går gjennom som før, så en betalingsmur som står fra før, kan tas av. Nyhetene på et nettsted er åpne for alle, og MCP-verktøyet publish_post får det samme svaret.

Lagt tilToppseksjonene i butikken

GET og PUT /api/v1/shop/masthead leser og erstatter teksten over produktene i butikken, og GET og PUT /api/v1/shop/categories/{slug}/masthead gjør det samme for en kategori. Tilgangene er products:read og products:write, de samme som for kategoriregisteret. PUT tar title og blocks, med blokkene i samme format som på en side, og erstatter det som står der. En html-blokk gir 422 html-block-not-allowed, og en kategori som ikke står i registeret, gir 404 unknown-category. Uten nettbutikk svarer vi 409 shop-not-enabled. MCP-verktøyene heter get_shop_masthead og set_shop_masthead, og tar category for en kategori.

Lagt tilDesignet på et nettsted

GET og PATCH /api/v1/site-design leser og endrer det byggeren kaller Utseende på et nettsted: width, spacing, typography, color, section_style og formen (corners, buttons, padding, gap og text_size). Tilgangene er style:read og style:write, de samme som for /api/v1/style. Send bare det du vil endre. Hver verdi er en fast nøkkel, og en ukjent gir bad-<felt> med lista i allowed. Bredde og avstand kan alle endre. Resten krever en pakke, og uten den svarer vi 403 design-plan-required før noe er lagret. design_unlocked i svaret sier om publikasjonen har pakken. En blogg svarer 409 not-a-site-publication. MCP-verktøyene heter get_site_design og set_site_design.

Lagt tilLenkene i bunnen av nettstedet

GET og PUT /api/v1/footer-columns leser og erstatter kolonnene med lenker i bunnen av hver side, med tilgangene pages:read og pages:write. Det er plass til tre kolonner med en overskrift og inntil seks lenker hver, og en lenke går til en sti på nettstedet eller en https-adresse. Tom liste gir standardkolonnen tilbake. Nye koder: bad-footer-columns, too-many-footer-columns, bad-footer-heading, too-many-footer-links og bad-footer-link, med index for kolonnen og link for lenka. MCP-verktøyene heter get_footer_columns og set_footer_columns.

EndretÅ publisere sender nyhetsbrevet bare med newsletter:send

Når et innlegg publiseres for første gang, går nyhetsbrevet ut til abonnentene. Til nå holdt det med posts:write, så en nøkkel uten newsletter:send kunne likevel sende e-post til alle. Nå sender publiseringen bare når nøkkelen har newsletter:send. Uten den blir innlegget publisert uten e-post, og ber du om utsendingen med send_newsletter: true, svarer vi 403 missing-scope:newsletter:send. Det gjelder POST /api/v1/posts, PATCH /api/v1/posts/{id} og POST /api/v1/posts/{id}/schedule. En nøkkel med newsletter:send merker ingen forskjell. POST /api/v1/news fra skribbs egen app er som før.

Lagt tilSider kan ligge under andre sider, og menyen kan samle lenker

En Page har et nytt felt, parent: slugen til sida den ligger under, eller null når den ligger øverst. PUT /api/v1/pages/{slug} tar det imot, og uten feltet står det som før. Adressen endrer seg ikke, men sida viser en sti over tittelen og i de strukturerte dataene: Forside, sida over, denne sida. Det er bare ett nivå, så sida over må ligge øverst selv, og en side med sider under seg kan ikke legges under en annen. Det gir 422 parent-too-deep, en side som ikke finnes gir 422 no-such-parent, og sida selv eller forsida gir 422 bad-parent. DELETE svarer 409 page-has-children så lenge sider ligger under den. I menyen kan en MenuItem ha children, inntil ti lenker som vises under den. Flere gir 422 too-many-children, og når et kall blir avvist på grunn av en av dem, sier child i svaret hvilken. En meny uten children ser ut som før, også i svaret fra GET /api/v1/menu. Verktøyet publish_page tar parent, og med in_menu legger det sida under lenka til sida over når den står i menyen.

Lagt tilEgen beskrivelse og delingsbilde på sider

En Page har to nye felter, seo_description og og_image. De står i GET /api/v1/pages og i én side, og PUT /api/v1/pages/{slug} tar dem imot. Tom tekst betyr at nettstedet henter beskrivelsen og bildet fra blokkene, slik det har gjort til nå. PUT uten feltene lar dem stå som de er, så en integrasjon som bare sender title og blocks, visker ikke ut det skaperen har skrevet i nettstedbyggeren. En beskrivelse over 160 tegn gir 422 bad-seo-description, og en bildeadresse som ikke er http, https eller en sti på nettstedet, gir 422 bad-og-image. Verktøyet publish_page tar de samme feltene.

Lagt tilForsida kan skrives gjennom API-et

GET og PUT /api/v1/pages/home leser og erstatter forsida, med tittel og blokker i samme form som de andre sidene. Før svarte begge 422, så en side flyttet inn fra et annet nettsted måtte legges på forsida for hånd. Forsida teller ikke med i hvor mange sider nettstedet kan ha, og GET /api/v1/pages lister den fortsatt ikke. DELETE /api/v1/pages/home svarer 409 cannot-delete-home, og menyen tar fortsatt ikke /home: forsida ligger på /. Verktøyet publish_page i MCP-serveren skriver forsida med slug home, og legger den ikke i menyen selv om du ber om det. blogg, butikk og preview avvises som før.

Lagt tilBedriftsprofilen

GET /api/v1/business-profile henter adressen, telefonnummeret, e-posten, åpningstidene og området bedriften dekker, og PATCH endrer det du sender. Det er de samme feltene som under Innstillinger → Nettsted, og de står i bunnen av sidene og i de strukturerte dataene søkemotorene leser. Ruta bruker publication:read og publication:write, så en nøkkel som har dem fra før, når den uten noe mer. En verdi skjemaet ville rettet på, blir avvist med en kode som navngir feltet. Kommunen, næringskoden og organisasjonsformen kommer fra Enhetsregisteret og gir 422 read-only-field, og et nettsted som ikke tilhører en bedrift, svarer 409 not-a-business. Verktøyene i MCP-serveren heter get_business_profile og set_business_profile.

Lagt tilVideresendinger fra gamle adresser

GET og PUT /api/v1/redirects leser og erstatter lista over gamle adresser som skal sende videre med 301, med tilgangene pages:read og pages:write. Målet må være en sti på nettstedet eller en adresse på nettstedets eget domene. En videresending gjelder bare adresser nettstedet ellers ville svart 404 på. Det er plass til 200. Nye koder: bad-redirect-from, bad-redirect-to, duplicate-redirect, redirect-loop og too-many-redirects, alle med index for regelen det gjelder. MCP-verktøyene heter get_redirects og set_redirects.

Lagt tilNyheter fra skribb-appen

POST /api/v1/news publiserer en nyhet med bilde, tittel og noen linjer fra skribb-appen, med tilgangen posts:write. Ruta er bare for skribb-appen og følger med Skribb Mer: et annet program får 403 skribb-app-only, en publikasjon uten Mer får 403 app-news-needs-mer, og et nettsted med Nyheter slått av får 409 news-disabled. POST /api/v1/posts svarer som før.

Lagt tilSvarmaler

GET /api/v1/messages/svarmaler gir svarene skaperen har lagret for å sette inn når de svarer. Ruta bruker messages:read, så nøkler som alt leser meldinger, kan bruke den. Svarmaler følger med Skribb Mer, og uten den svarer ruta 409 med den nye koden mer-plan-required. Malene skrives i oversikten, så ruta bare leser.

Lagt tilAutosvar i chat-tråden

En ChatMessage har et nytt felt, auto_reply. Det er true på autosvaret skribb sender når en besøkende skriver utenfor åpningstid, og false ellers. Et autosvar har sender creator, som før, så en integrasjon som bare leser sender, viser det som et svar fra bedriften. Skal du vite om noen faktisk har svart, ser du bort fra meldinger med auto_reply true.

Lagt tilAngrerett på bestillinger

En bestilling har to nye felter, return_requested_at og return_closed_at: når kjøperen brukte angreretten, og når du merket det som håndtert uten å betale tilbake. De står overalt der en bestilling står, i GET /api/v1/orders, i én bestilling, i svaret fra fulfill og refund og i order-webhookene. Ingen eksisterende felt endrer seg, og feltene er null på bestillinger ingen har angret.

Lagt tilLedige tider for avtaler

GET og PATCH på /api/v1/bookings/availability leser og endrer uka du tar imot avtaler i, og hvor lang hver avtale er. GET gir også hver dato framover med alle tidspunktene den har, og om de er ledige. Feltet addon_active i svaret sier om publikasjonen har tillegget Avtaler, og opening_hours gir åpningstidene i samme form som uka, klare til å sendes med PATCH. POST /api/v1/bookings/availability/dates legger til eller tar bort en tid på én dato, eller stenger og åpner dagen, uten å røre uka. Rutene bruker bookings:read og bookings:write, så nøkler som har dem fra før, når de nye rutene uten noe mer.

Lagt tilskribb-appen kan merke varsler som lest

POST /api/v1/notifications/read merker varslene i oversikten som lest, etter type, med den nye tilgangen notifications:write. Ruta er bare for skribb-appen: en nøkkel du har laget selv, eller et annet program, får 403 skribb-app-only, og /gi-tilgang avviser notifications:write med invalid_scope når et annet program ber om den. Tillegg E i databehandleravtalen har fått versjon 2.3. Til eieren har godtatt den, svarer /api/v1/subscribers med 403 og dpa-not-accepted. Resten av API-et svarer som før.

Lagt tilTelefoner for varsler fra skribb-appen

POST, PATCH og DELETE på /api/v1/devices melder på og av telefoner som skal få varsler fra skribb-appen, med den nye tilgangen devices:write. Rutene er bare for skribb-appen: en nøkkel du har laget selv, eller et annet program, får 403 skribb-app-only, og /gi-tilgang avviser devices:write med invalid_scope når et annet program ber om den. Vil du høre når noe skjer, er webhooks veien. Tillegg E i databehandleravtalen har fått versjon 2.2. Til eieren har godtatt den, svarer /api/v1/subscribers med 403 og dpa-not-accepted. Resten av API-et svarer som før.

EndretAdresser på skribb.no er forbeholdt skribbs egne apper

Registrering på /oauth/register avviser nå redirect_uris på skribb.no og underdomenene, og URI-skjemaer som begynner med no.skribb, med invalid_redirect_uri. Godkjenningssiden viser skaperen hvor koden sendes, og den adressen skal ikke kunne se ut som skribb når det er et annet program som spør. Programmer som alt er registrert, virker som før.

Lagt tilAvtaler i API-et

Forespørslene fra avtaleskjemaet kan nå leses og besvares med GET, PATCH og DELETE på /api/v1/bookings, med to nye tilganger: bookings:read og bookings:write. Et svar sender den besøkende den samme e-posten som når du svarer fra Avtaler i skribb. Nøkler du har fra før, får ikke de nye tilgangene av seg selv: lag en ny nøkkel, eller be om tilgang på nytt, med avtalene huket av. Fordi en nøkkel nå kan nå telefonnumre, har Tillegg E i databehandleravtalen fått versjon 2.1. Til eieren av publikasjonen har godtatt den under Innstillinger, svarer /api/v1/subscribers med 403 og dpa-not-accepted, slik den gjorde før Tillegg E var godtatt første gang. Resten av API-et svarer som før.

Lagt tilWebhooks for lager

To nye hendelser du kan hake av for: stock.changed hver gang en beholdning flytter seg, og stock.low når en vare krysser grensen for å gå tom. Bodyen er den samme for begge og sier hvor beholdningen står nå, hva den sto på før og hva som flyttet den. Du får én hendelse per vare og ikke én per bevegelse, så en bestilling på tre varelinjer gir tre. Sammen med PATCH /api/v1/products/{id}/stock er dette begge veier av en lagersynk mot et kassasystem. Ingen eksisterende webhook endrer seg: en adresse får de nye hendelsene først når du har haket dem av.

EndretOpplastede filer lagres hos publikasjonen

POST /api/v1/media og /api/v1/media/from-url legger nå alle filer hos publikasjonen selv. For purpose=image betyr det to ting: svaret har en id i tillegg til url, og url-en peker på publikasjonens egen adresse i stedet for media.skribb.no. Feltet key er borte for image og står bare for delivery, der det er nøkkelen du setter som delivery_file_key. Grensene og feilkodene er de samme. Bilder du allerede har lagt på produkter, virker som før.

Lagt tilNyhetsbrevet har fått maler

GET og PATCH /api/v1/newsletter har et nytt felt, template, med verdiene klassisk, moderne, kompakt, merkevare og ren-tekst. Malen bestemmer oppsettet i e-posten: skrift, spaltebredde, hvordan navnet står øverst og hvordan knappene tegnes. Den bestemmer ingen farge: aksentfargen, tekstfargen på den og skriften kommer fra publikasjonen som før, og malen avgjør bare hvor mye av siden hver av dem får. klassisk er standard og er nøyaktig den e-posten som gikk ut før, så en publikasjon som ikke rører feltet sender akkurat det samme som i går.

EndretEn full liste svarer 409 i stedet for å sende en bekreftelse

POST /api/v1/subscribers svarer 409 list-full når publikasjonen har like mange abonnenter som pakken dekker. Før sendte vi bekreftelsen uansett, og den ble avvist når mottakeren trykket på lenka: en e-post som bare kunne ende i et nei. Feilen sier noe om lista og ingenting om adressen, så ruta svarer fortsatt likt for alle adresser og kan ikke brukes til å sjekke hvem som står på lista. Antallet pakken dekker står i pakkeoversikten, og du utvider det med en abonnentblokk.

Lagt tilEn forside som leder med påmeldingen

home_layout tar en femte verdi, subscribe-first. Forsiden blir da påmeldingen, med alt du har sendt listet under den i stedet for et fremhevet innlegg og et rutenett. Det er verdien et nyhetsbrev opprettes med, og du kan sette den på en hvilken som helst publikasjon gjennom PATCH /api/v1/publication/style. De fire gamle verdiene betyr det samme som før.

Lagt tilTre nye hendelser du kan abonnere på

subscriber.unsubscribed, broadcast.sent og broadcast.failed er nye i webhook-oppsettet. subscriber.unsubscribed går én gang, når abonnenten melder seg av, ikke hver gang noen melder av den samme adressen: er den avmeldt fra før, skjer det ingenting. broadcast.sent og broadcast.failed har utsendingen i samme form som GET /api/v1/broadcasts/{id}, med recipient_count og sent_count, så du kan sammenligne de to tallene rett fra bodyen. Kundepost fra et nettsted utløser ingen av dem, siden den heller ikke ligger i /api/v1/broadcasts. Du må huke av for dem i innstillingene, som for de andre hendelsene.

RettetEn utsending som ikke kommer fram, gir seg

status kan nå være feilet. Før ble en utsending vi ikke fikk levert til publikasjonen stående som sender for alltid, og vi prøvde igjen hvert femte minutt uten å si fra til noen. Nå prøver vi i to timer og gir oss så: status blir feilet, og i oversikten står den som en e-post som ikke kom fram. DELETE på en feilet utsending svarer 409 broadcast-failed, for en publikasjon vi ikke når kan ha rukket å sende deler av lista, og da kan vi ikke skrive at den ble avlyst. POST /api/v1/broadcasts/{id}/send sender den om igjen når publikasjonen svarer, og publikasjonen fører selv lista over hvem som har fått den, så ingen får den samme e-posten to ganger.

Lagt tilUtsendinger: skriv en e-post til lista, og send den

/api/v1/broadcasts er en e-post du skriver selv og sender til abonnentene, uten at det ligger et innlegg bak. GET lister dem, POST skriver en, POST /{id}/send sender eller planlegger, DELETE avlyser. Teksten er Portable Text i body, eller Markdown i markdown, og post_slugs legger innleggskort under den: publikasjonen slår innleggene opp selv når e-posten går ut, så et innlegg som er avpublisert i mellomtida faller ut i stedet for å bli en død lenke. Å skrive og å sende er to tilganger, broadcasts:write og newsletter:send, og alt som faktisk sender krever Idempotency-Key. MCP-serveren har fått find_broadcasts, get_broadcast, write_broadcast, send_broadcast og cancel_broadcast.

Lagt tilAbonnentlista kan skrives til, uten at noen kan legges inn uten å si ja

Ny tilgang subscribers:write. POST /api/v1/subscribers ber en adresse om å bekrefte og svarer 202, ikke 201: adressen dukker ikke opp i GET /api/v1/subscribers før den er bekreftet, så lytt på subscriber.confirmed. DELETE /api/v1/subscribers/{email} melder av; adressen er id-en. Begge rutene krever Tillegg E, som lesinga, og de har en egen og strammere grense enn resten av API-et. Resten står under Abonnenter i referansen.

Lagt tilNyhetsbrevet er noe en integrasjon kan lese og sette

GET /api/v1/newsletter gir hvordan e-posten til abonnentene ser ut og leses, og PATCH endrer det du sender. Tilgangene heter newsletter:read og newsletter:write, de er egne fra newsletter:send, og en nøkkel du har fra før har ingen av dem. To ting skiller ruta fra skjemaet i oversikten: en for lang tekst blir avvist med koden <felt>-too-long og grensen i max, og en svaradresse uten Skribb Mer svarer 409 premium-plan-required. Resten står under Nyhetsbrev i referansen.

RettetProduktene får betal det du vil, og viser salget

POST og PATCH /api/v1/products tar nå pwyw, og Product har fått pwyw og sale. Før ble pwyw ikke lest fra bodyen, så en PATCH skrudde stille av betal det du vil på et produkt der skaperen hadde slått det på i oversikten, og ingenting i svaret viste det. PATCH tar fortsatt hele produktet, så send pwyw: true om det skal stå. sale er salget som står på produktet, og er bare til å lese: et salg startes og avsluttes i oversikten, der førprisen regnes ut fra prishistorikken. Verktøyet save_product i MCP-serveren har fått det samme feltet.

Lagt til/me sier også om kontoen har et domene

products har fått et fjerde produkt, domene. Det står enabled når skaperen som eier publikasjonen, har et domene hos oss, eller en bestilling som er betalt og på vei inn. Domenet hører til kontoen og ikke til én publikasjon, så to publikasjoner under samme skaper svarer likt. Det sier ikke at publikasjonen svarer på domenet: hvilken adresse som gjelder, er GET /api/v1/domain, som er uendret. plan står alltid null, for domenet fornyes årlig utenfor pakkene.

EndretEn side som ligger i menyen, kan ikke slettes

DELETE /api/v1/pages/{slug} svarer 409 page-in-menu når menyen fortsatt peker på sida, og menu i svaret sier hvilke lenker det gjelder. Før slettet den sida og lot lenka bli stående, så toppen av nettstedet pekte til ingenting. PUT /v1/menu har hele tiden nektet å lage den tilstanden. Rekkefølgen er nå: ta lenka ut av menyen, så slett sida. Nettstedbyggeren gjør det samme, med en lenke rett til menyen.

Lagt tilHente et bilde fra en adresse

POST /api/v1/media/from-url henter et bilde du peker på, og legger det der du sier. Svaret er det samme som fra opplastingsruta, så id-en du får med purpose=post, er den du setter som featured_image på et innlegg. Nytten er størst for et program som skriver JSON og ikke har bildet på disk: opplastingsruta tar multipart, og har derfor ikke noe verktøy i MCP-serveren. Vi henter bare over https, følger inntil tre videresendinger og sjekker hver adresse på veien, tar PNG, JPG, WebP og GIF etter innholdstype og ikke etter filendelse, og leser aldri mer enn 5 MB. SVG tar vi ikke. Tilgangen er media:write, den du har fra før. Verktøyet heter add_image.

Lagt tilAdressen publikasjonen svarer på

GET /api/v1/domain sier hvilket domene publikasjonen svarer på, om det er i drift, og hva som eventuelt mangler. Er domenet kjøpt et annet sted og koblet til, får du postene du skal legge inn hos leverandøren din, og mens vi venter på dem slår vi dem opp: state på hver post sier om vi fant den, om det står noe annet der, eller om det ikke er lagt inn ennå. Er domenet kjøpt gjennom skribb, ligger DNS-en hos oss, og du får registreringen i stedet, med fornyelsesdato. Ny tilgang domain:read. Ruta leser bare. Å kjøpe, flytte eller si opp et .no er en erklæring fra den som eier navnet, så noe skrivende motstykke kommer ikke.

Lagt tilMenyen på nettstedet

Sider kunne lages, men ingenting kunne lenke til dem. GET /api/v1/menu henter menyen øverst på nettstedet, og PUT erstatter hele lista, der rekkefølgen du sender, er rekkefølgen som vises. En lenke går til en sti på ditt eget nettsted eller til en full nettadresse. Peker den på en side du ikke har, blir kallet avvist med no-such-page, og svaret lister sidene som finnes. Menyen ligger under tilgangene pages:read og pages:write, de samme som sidene, så en nøkkel som kan lage sider, kan også lenke til dem.

Lagt tilSette utseendet på publikasjonen

Utseendet er nå noe en integrasjon kan lese og sette. GET /api/v1/style gir tema, fargemodus, aksentfarge, skrifter og leseflate, og PATCH endrer det du sender. Verdiene er de faste nøklene fra palettene våre, og en verdi utenfor dem blir avvist med et svar som lister alt ruta tar imot. Fargekoder tar den ikke: hver nøkkel er målt mot WCAG AA før den ble lagt til, og egne farger setter du under Finjustering, der vi kan måle dem mens du velger. Tilgangene heter style:read og style:write, og en nøkkel du har fra før har ingen av dem.

Lagt tilEndre innstillingene for publikasjonen

GET /api/v1/publication henter tittelen, undertittelen, «Om»-teksten i bunnen og om publikasjonen skal finnes i søk. PATCH endrer feltene du sender og lar resten stå. To nye tilganger følger med, publication:read og publication:write. Nøkler du allerede har laget, har ingen av dem. Skal en integrasjon endre innstillinger, huker du av for tilgangen på en ny nøkkel, eller ber om den i godkjenningen.

Lagt tilBe om tilgang på vegne av en skaper

Bygger du noe andre skal bruke, slipper de å lime inn en nøkkel hos deg. Programmet registrerer seg selv på POST api.skribb.no/oauth/register, sender skaperen til skribb.no/gi-tilgang for å godkjenne, og bytter koden i et token på api.skribb.no/oauth/token. Tokenet varer én time og sendes som bearer akkurat som en nøkkel, så ingenting du har bygget mot API-et, endrer seg. Flyten står beskrevet på /.well-known/oauth-authorization-server og /.well-known/oauth-protected-resource, så en klient som bare kjenner adressen vår, finner fram selv.

Endret401 peker på hvor tilgang fås

WWW-Authenticate på et 401-svar har nå resource_metadata med adressen til /.well-known/oauth-protected-resource, slik RFC 9728 beskriver. Der står det hvilken tjeneste som gir tilgang, så en klient kan gå fra et 401 til en godkjenning uten at noen leser en side først. Bodyen og error="invalid_token" er uendret.

EndretEnkel låser opp meldingene

Kontaktskjemaet følger nå med begge nettsted-pakkene, ikke bare Komplett. Meldingsrutene svarer tilsvarende: har publikasjonen Enkel, får du 200 der du før fikk 409. Chat krever fortsatt Komplett, så på Enkel er chat-lista bare tom. Feilkoden for et nettsted helt uten abonnement heter fremdeles komplett-plan-required: navnet er fra da skjemaet fulgte Komplett, og det står fordi noen kan ha bygget mot det.

Lagt tilPlanlegg uten å sende nyhetsbrevet

send_newsletter: false virker nå også når du setter et innlegg i kø. Utsendingen stanses med det samme, ikke når cron-jobben publiserer: da er det ingen å svare til, og en sperre som feilet i det øyeblikket, ville blitt en e-post ingen ba om og ingen kunne stoppe. Får vi den ikke stanset, blir innlegget ikke satt i kø.

Lagt tilPubliser uten å sende nyhetsbrevet

send_newsletter: false sammen med publish: true publiserer stille. Standarden er uendret: publiserer du et innlegg som aldri har vært ute, går nyhetsbrevet fortsatt. Får vi ikke stanset utsendingen, publiserer vi heller ikke. Du får 502 og innlegget står som kladd, så en sperre som ikke virket, aldri blir til en e-post til alle. Sender du feltet uten publish, svarer vi 422 i stedet for å overse det.

Lagt tilPlanlegg et innlegg

POST /api/v1/posts/{id}/schedule setter en kladd i kø, GET viser når den går ut og hva som eventuelt gikk galt, DELETE avlyser. Det er den samme jobben som publiserer det du planlegger i oversikten, ikke en ny. publish_at er ISO 8601, ikke Oslo-tid: du sender et øyeblikk, og vi gjetter ingen tidssone på dine vegne. Krever en betalt pakke på publikasjonen, ellers 409 plan-required.

Lagt tilslug gjør opprettelse av innlegg idempotent

Sender du slug til POST /api/v1/posts, eier den adressen: kommer samme slug inn igjen, svarer vi 409 slug-taken i stedet for å lage en tvilling. Det er en annen garanti enn Idempotency-Key, som dekker én forespørsel i et døgn; slugen dekker «har jeg skrevet dette før» på tvers av kjøringer. Utelater du slug, er alt som før, og adressen settes av tittelen.

Lagt tilForsidebilde på et innlegg

Last opp med purpose=post, og sett id-en du får som featured_image på innlegget. Innlegg svarer nå også med featured_image når de har ett. purpose=image er uendret og fortsatt det du bruker på et produkt: de to bildene ligger ikke samme sted, og et innlegg viser til sitt med en id, ikke en adresse.

Lagt tilMeldinger kan svares på, arkiveres og slettes

Ny tilgang messages:write. Du kan flytte et kontaktskjema til replied eller archived, åpne og lukke en chat-samtale, svare den besøkende i chat, og slette begge deler. Chat-svaret går i tråden og vises neste gang widgeten spør. Et svar på et kontaktskjema er fortsatt ikke med: det går ut som e-post, og hvilken adresse den besøkende svarer tilbake til, er ikke et valg en nøkkel skal ta. Har du svart fra ditt eget system, sier du fra med status replied.

Lagt tilMeldinger blar, og kan hentes én om gangen

/messages/kontakt og /messages/chat er nye lister med cursor, statusfilter og, for chat, updated_since. /messages selv er uendret, men blar ikke og gjør det aldri: to lister i én body kan ikke dele én cursor. Chat-lista svarer uten meldingene, så hent den enkelte samtalen for tråden.

Lagt til/me sier hvilke produkter publikasjonen har

Svaret har fått products, med publikasjon, nettsted og nettbutikk, og pakken på hver: pro, enkel eller komplett, eller null for gratisnivået. Da slipper du å kalle en rute for å finne ut at den svarer 409, og du kan endelig se forskjell på Enkel og Komplett. kind og shop_enabled står som før, så ingenting som leser dem, merker noe.

EndretMeldinger svarer 409 uten Komplett

GET /api/v1/messages svarte 200 med tomt svar for en publikasjon som ikke har kontaktskjema og chat i det hele tatt, altså det samme som en rolig uke. Nå kommer 409 komplett-plan-required.

EndretBestillingsrutene krever at nettbutikken er slått på

GET /api/v1/orders, GET /api/v1/orders/{id} og POST /api/v1/orders/{id}/fulfill svarte 200 med tom liste når butikken var av, som er umulig å skille fra «ingen bestillinger ennå». Nå svarer de 409 shop-not-enabled, slik produktrutene og refusjonsruta alltid har gjort.

Rettetbearer med liten forbokstav ble avvist

Authorization: bearer <nøkkel> svarte 401 missing-bearer, altså at forespørselen ikke hadde noen nøkkel i det hele tatt. Navnet på metoden er ikke skiftsensitivt, så begge skrivemåter virker nå.

Endret401 svarer med WWW-Authenticate

Et 401-svar har nå WWW-Authenticate: Bearer, og error="invalid_token" når nøkkelen fantes, men ikke holdt. Bodyen er den samme, så ingenting som leser error, merker noe.

Rettetfield navnga et felt som ikke fantes i bodyen

bad-price svarte med field: "price" og bad-weight med field: "weight". Feltene heter price_ore og weight_grams på wire, så svaret pekte på en nøkkel du ikke ville finne i din egen body. Kodene er uendret; det er bare field som nå navngir det ekte feltet.

RettetTre koder svarte med en generisk melding

digital-needs-delivery, not-configured og no-pat kom med «Forespørselen kunne ikke behandles» i stedet for noe som forklarte hva som var galt. Alle tre har nå en egen melding. Kodene er uendret.

Endretdocs i feilsvaret peker på en mer presis side

Referansen er delt i en side per ting du kan gjøre, så docs peker nå på den siden, og på raden for den enkelte koden når det ikke finnes en mer forklarende side. Gamle lenker med #anker leder fortsatt til riktig sted via oversikten.

DokumentasjonOpenAPI beskriver bodyene, ikke bare rutene

/api/v1/openapi.json har nå requestBody, svarskjema per rute og ett komponentskjema per objekt. En klientgenerator gir deg typede kall i stedet for URL-stubber. Ingenting i API-et er endret; dokumentet beskriver bare mer av det som alltid har vært der.

Lagt tilNotater, meldinger, innsikt, kategorier og filopplasting

POST og GET /notes under posts-tilgangene. GET /messages under messages:read. GET /insights under analytics:read. GET og PUT /shop/categories. POST /media, det ene stedet som tar imot multipart i stedet for JSON.

Lagt tilMarkdown inn og ut på innlegg

Du kan sende markdown i stedet for content, og lese med ?format=markdown. content er fortsatt fasiten: markdown_dropped navngir blokkene Markdown ikke kunne bære.

Lagt tilWebhooks

Signerte POST-er på order.paid, order.fulfilled, order.refunded, subscriber.confirmed og post.published, med fem forsøk over rundt åtte timer.

Lagt tilIdempotency-Key, paginering og ?updated_since=

Opprettingsrutene husker svaret i et døgn per nøkkel. Lister svarer med has_more og next_cursor. Produkter og bestillinger kan hentes etter når de sist ble endret.

EndretFeilsvaret fikk message, field og docs

Den var {"error": "bad-slug"} og ingenting mer. error er uendret og fortsatt det eneste du bør bygge logikk på, så ingenting som leste den, sluttet å virke.

RettetTidspunkter kommer som ekte ISO 8601

Datofeltene svarte med SQLites eget format, som ingen dato-parser tar imot uten hjelp. Nå er alt ISO 8601 i UTC.

Lagt tilGET /api/v1/me

Svarer på enhver gyldig nøkkel og forteller hvilken publikasjon den gjelder og hva den får lov til. Det første kallet i en ny integrasjon.

Lagt tilv1 åpnet

Nøkler med avhuking per tilgang, og de første rutene: produkter og lager, bestillinger med frakt og refusjon, innlegg, sider, abonnenter og butikkinnstillinger.