DCSA API-standarder för global tillgång till sjöfartsdata

DCSA:s API-standarder: Gör data tillgänglig inom den globala sjöfartsindustrin

Implementera DCSA API:er nu: prioritera slutpunkterna för bokning, händelser och spårning och anamma standardiserade nyttolaster inom 12 veckor för att minska manuella beröringspunkter med ~40 % och leverera uppdateringar i nära realtid till varje användare.

Börja med tre praktiska steg: kartlägg befintliga gränssnitt, exponera ett tunt API-lager för äldre system som fortfarande använder EDI, och pilotera satellitbaserade positionsflöden för att berika händelseregister. Detta tillvägagångssätt bevarar nuvarande operationer samtidigt som det skapar en sömlös väg för automatiska meddelanden och ETA-korrigeringar.

Mät resultat för att bevisa värde: spåra genomsnittlig tid till bekräftelse för en bokning, procentuell minskning av e-posttrådar, frekvens av statusuppdateringar per resa, och användning av API-anrop per kund. Dessa mått visar hur transformationen omformar upphandling och drift över hela leveranskedjan och hur team samarbetar för att minska väntetid och feldirigering på ett fartyg.

Följ tydliga planer: genomför en tre-delars pilot med ett rederi, två avsändare och en terminal; publicera SLA- och versionsregler; tillhandahåll SDK:er och exempelnyttolaster; och schemalägg veckovisa integrationskontroller. Dessa konkreta steg ger upprepningsbara resultat idag och gör standardiserad data tillgänglig för nedströmsystem, analys och partnerintegrationer.

DCSA API-standarder: Gör data tillgänglig inom global sjöfart – Synkroniserar ankomster av containerfartyg och plattformsutplacering för digitalisering

Implementera DCSA API-standarder inom 12 månader för att synkronisera publicering av fartygs ETA, kajallokering och plattformsutplacering, vilket minskar manuella överlämningar och möjliggör automatiska operativa uppdateringar.

Kräv API:er för att publicera ETA- och statusuppdateringar med 15-minuters intervaller och stöd för händelsedrivna webhooks för omedelbar kommunikation mellan rederier, terminaler och agenter. Integrera AIS och satellitflöden så att position och hastighet fångas längs rutten och överförs till hamnsystem; standardisera nyttolaster med ISO 8601-tidsstämplar och UN/LOCODEs för att undvika mappningsfel under överföring. Planera tre stora releaser per år med semantisk versionshantering och tydligt publicerade fönster för bakåtkompatibilitet för att ge användarna förutsägbara uppgraderingscykler.

Optimera kajfönster genom att kombinera operativa flöden från terminaloperativa system och rederiplaneringssystem; piloter med Maersk och terminalpartners visar upp till 20 % minskning av kajväntetid och en högre kajutnyttjandegrad jämfört med manuell schemaläggning. Använd automatiska regler för kajåterallokering och meddelanden för att minska kajens inaktiva minuter mellan fartygsrörelser, vilket förbättrar genomströmningen mer än vad ad hoc-meddelanden kan uppnå.

Inkludera miljömässiga mätvärden i varje API-nyttolast: bränsleförbrukning, timmar för hjälpmaskiner och satellitbaserade emissionsuppskattningar. Mata dessa fångade mätvärden in i hamn- och rederihanteringspaneler för att kvantifiera CO2 per TEU och sätta mätbara mål för hållbar utveckling. De gör det möjligt för operatörer att jämföra rutt- och kajval när det gäller utsläpp och driftkostnader, vilket möjliggör strategiska val som ger bättre hållbarhetsresultat.

Etablera styrning som kopplar standardöverensstämmelse till kontraktuella SLA:er, klargör kommunikationsprotokoll och tilldelar ansvar för datakvalitet. Främja utvecklarverktyg, sandbox-miljöer och öppen dokumentation för att påskynda utveckling och introduktion av nya användare. Övervaka KPI:er – ankomsttidens noggrannhet, automatisk överföringssuccesfrekvens och minskning av manuella ingripanden – och publicera kvartalsrapporter så att intressenter kan mäta framsteg och planera ytterligare integration.

Operativ ritning: Tillämpa DCSA API:er för att inrikta fartygsankomstdata

Implementera en standardiserad process för avstämning av ankomststatus med hjälp av DCSA Event, Voyage och Port Call API:er med en SLA på 24 timmar för att synkronisera fartygsankomster mellan rederier, hamnar och terminaler.

Fånga ankomstdata från tre primära källor: rederimanifest via DCSA Voyage API, terminalsystem via Port Call API och AIS-flöden. Använd Event API webhooks för snabba uppdateringar och använd periodisk polling med 5-minuters intervall när webhooks misslyckas. Tagga varje post med ett SOURCE-fält (källa) och en capture_timestamp för att bevara ursprung och stödja revisionsspår.

Normalisera inkommande nyttolaster till en enda operativ modell med dessa specifika kanoniska fält: vessel_imo, voyage_id, eta_utc, ata_utc, berth, status_code, bunker_onboard_mt, estimated_fuel_burn_mt, customs_status och event_origin. Konvertera alla tider till UTC, avrunda till närmaste minut, och mappa disparata statuskoder till en 7-fasig ankomsttaxonomi (planerad, ETA uppdaterad, på väg, anlände, vid kaj, förtöjd, avgått).

Använd deterministiska matchningsregler: exakt matchning på vessel_imo + voyage_id om tillgängligt; annars matchning på vessel_imo + eta-fönster ±72 timmar med en poängfunktion som viktar Event API = 0.5, AIS = 0.3, terminalmeddelanden = 0.2. Markera avvikelser med en poäng <0.6 för mänsklig granskning. Definiera en avvikelsesträngel på 60 minuter för ETA vs ATA; behandla större luckor som operativa undantag som kan öka bränsleanvändningen och tullklareringstiden.

Integrera undantagshantering i användargränssnitt och maskinella gränssnitt samtidigt. Skicka höggradiga undantag till rederiets operativa team via API-meddelanden och till terminalplanerare via UI-paneler. Ge användarna föreslagna korrigerande åtgärder: omdirigera till alternativ kaj, begär omedelbar bunkerjustering, eller förhandsgodkänn tullhandlingar. Registrera operatörsbeslut och tid till lösning för senare analys.

Mät prestanda med dessa KPI:er och mål: discrepancy_rate (<5 % inom 6 månader), mean_time_to_align (<4 timmar), SLA_adherence (≥98 %), bunker_variance (±3 % av rapporterad ombord), och economic_impact_estimate per ankomst. Använd de senaste tre månaderna som baslinje och kör en pilot i oktober på en ledande Asien-Europa-rutt med 500 fångade ankomster för att validera besparingar och modellnoggrannhet.

Tillämpa transformationsregler som minskar duplicerade händelser och förbättrar nyttjandet av systemgränssnitt: släpp dubbletter inom 2 minuter från samma källa, slå samman händelser som delar identisk vessel_imo+event_origin+timestamp, och lagra råa nyttolaster för linjege. Annotera poster med ett events_history-fält så att analytiker kan förstå tidmönster som ledde till avvikelser längs resan.

Styr dataflöden med versionerade API-kontrakt, OAuth2-tokens per partner, hastighetsgränser anpassade till toppoperationer (rekommenderade 1 200 anrop/min för Event-prenumerationer), och lagringspolicyer (råa i 12 månader, aggregerade i 36 månader). Underhåll ett branschomfattande schema-register så att partner kan synkronisera fältsemantik och minska mappningsarbetet utöver den initiala integrationen.

DCSA API	Viktiga fält som fångas	Åtgärd	SLA / Mål
Event API	event_type, timestamp, location, vessel_imo, voyage_id	Fångst i realtid, webhook först, avstämpning 2 min	Webhook-leverans <30s; försök igen två gånger
Voyage API	voyage_id, eta_utc, planned_port_calls, cargo_manifest	Fyll i kanoniska reseregister, markera manifestavvikelser	Synkronisera var 4:e timme; uppdateringar inom 1 timme
Port Call API	port_call_id, berth, alongside_time, berthed_time, customs_status	Synkronisera hamnrelaterad status, yta tullhinder	Uppdatera <15 min efter lokal händelse
Reference Data API	locations, terminals, carrier_codes	Lös upp namn/ID, minska mappningsfel	Veckovis uppdatering; snabblösningar inom 24 timmar
Location / AIS	lat, lon, sog, cog, timestamp	Komplettera ETA/ATA, uppskattning av bränsleförbrukning	Strömlatens <60s

Kör en tre månaders pilot med dessa steg: driftsätt integrationer på en ledande rutt i oktober, ta emot 500 tidigare och aktuella ankomster för att träna avstämningsmodellen, iterera regler för att minska falska positiva till <8 % och mäta ekonomisk påverkan månadsvis. Rapportera resultat till tullpartners för att förkorta klareringsfönster och till OPS-team för att minska väntetid som driver bränsleförbrukning. Använd lärdomar från piloten för att expandera branschövergripande och skala gränssnitt så att användare ser synkroniserade ankomstdata bortom lokala silos.

Identifiera kritisk slutpunktsuppsättning för avstämning av fartygsankomster: nödvändiga DCSA API:er och nyttolaster

Implementera denna minimala uppsättning av slutpunkter för att synkronisera fartygsankomster: Port Call (voyage/eta), Event Notifications (webhook), Transport/Movement, Booking, Equipment/Container, Terminal Interface, Reference/Location och Party API:er.

Port Call-nyttolast: inkludera voyageId, vesselIMO, vesselName, voyageNumber, portCode (UN/LOCODE), scheduledArrival (ISO-8601), estimatedArrival, scheduledDeparture, berthingWindowStart, berthingWindowEnd, berthCode, draftMeters, nextPortCode och sequenceVersion. Använd numeriska fält för TEU och djupgående, och ange sourceSystem och lastUpdatedBy. Till exempel: scheduledArrival: "2026-03-10T14:00:00Z". Överför hela reseresan vid första synkroniseringen och deltan därefter.

Event Notifications-nyttolast: eventType, eventTimestamp, relatedId (voyageId, containerNumber, bookingReference), locationCode, statusCode, details, sequenceNumber och idempotencyKey. Skicka POST-anrop med formatet application/vnd.api+json JSON:API till prenumerantens slutpunkter med försök/backoff och exponentiella fönster. Markera händelser som automatiska eller manuella och inkludera eventProvenance för att identifiera systemet som genererade händelsen.

Transport/Movement-nyttolast: transportId (GUID), shipmentId, bookingReference, carrierBookingReference, billOfLadingNumber, originUNLOC, destinationUNLOC, mode, containers:[{containerNumber,sizeType,status}], cargoType, weightKg, loadedOnVoyageId och currentStatusTimestamp. Tillhandahåll manifestReference och estimatedOnboardTime när det är tillgängligt för att hjälpa terminalplaneringen.

Booking-nyttolast: bookingReference, shipperPartyId, consigneePartyId, commodities, totalTEU, containerRequirements, portCutoffTimes:{terminalCutoff,gateCutoff,docsCutoff} med tidszon, requestedPickupDate och confirmedStatus. Använd dessa värden för att driva terminalslotting och mötessystem; lagra bookingVersion för avstämning.

Equipment/Container-nyttolast: containerNumber, isoSizeType, tareKg, grossKg, currentLocationCode, lastFreeTime, containerStatus och sealInfo. Kopplar dessa register till transportId och voyageId så att terminalsystem och kunder ser en enda sanningskälla.

Terminal Interface-nyttolast: terminalCode, berthCode, availableCraneCount, plannedBerthStart, plannedBerthEnd, gateSlots (tidsstämpelfönster), yardOccupancyPercent och serviceLevels. Designa modellen så att terminaler kan överföra kajbekräftelser och slot-tilldelningar tillbaka till Port Call- och Booking-domänerna.

Reference och Party-nyttolaster: partyId (rederi, terminal, avsändare, mottagare), names, roles, contactMethods och locationList. Leverera UN/LOCODE och standardiserade rolltermer för att främja konsekvent matchning över konstellationen av system som är involverade i sjöfart.

Protokoll och implementeringsregler: anta JSON:API innehållstyp, kräva RFC3339 tidsstämplar, genomdriva obligatoriska nycklar listade ovan, stödja PATCH för deltaförändringar, och versionera slutpunkter. Använd webhooks för automatisk händelsleverans och tillhandahåll en pull-API för fullständig synkronisering. Riktlinjer för hastighetsbegränsning: tillåt 5 anrop/sekund per klient för synkroniseringsslutpunkter och 1 000 webhook-händelser/min med backoff vid 429-svar.

Operativa rekommendationer: skicka ETA-uppdateringar oftare ju närmare ett fartyg är – till exempel, var 15:e minut när det är mer än 48 timmar bort, var 5:e minut inom 6 timmar, och omedelbart vid faktisk ankomst/förtöjning. Inkludera sequenceNumber och lastProcessedEvent i svar så att konsumerande system kan återuppta utan dubbletter och upprätthålla idempotens.

Övervakning och driftsättning: exponera mätvärden för deliverySuccessRate, averageLatencyMs och processingErrors per slutpunkt. Kör en driftsättningschecklista som inkluderar schemavalidering, webhook-försök, autentisering (mTLS eller OAuth2), och slut-till-slut-tester mellan rederi-, terminal- och kundsystem. Tilldela ett tvärfunktionellt team för att utveckla och övervaka dessa objekt under den första sprinten.

Mappnings- och datamodellvägledning: mappa lokala fält till kanoniska namn (voyageId, portCode, scheduledArrival) i ett integrationslager; bevara ursprungliga källidentifierare i ett sourceRef-fält. Använd en changeLog-modell som registrerar vem som ändrade vad och när för att driva nedströms avstämning och kundmeddelanden.

Säkerhet och styrning: kräva token-omfattningar per slutpunkt och begränsa data som returneras per roll. Registrera samtycke och avtalsvillkor för datadelning och inkludera auditTrail-poster för överförda händelser så att kunder och terminaler kan verifiera ursprung.

Påbörja implementeringen från en prioriterad checklista: 1) Port Call och Event webhooks, 2) Transport- och bokningssynkronisering, 3) Terminalgränssnitt och utrustning, 4) Konsolidering av referens- och partdata, 5) övervakning och driftsättningstester. Denna ordning minskar integrationsarbetet jämfört med ad hoc-metoder och låter teamet leverera synlig ankomstsynkronisering för försändelser inom veckor.

Översätt hamnanropshändelser till en kanonisk ankomsttidslinje: mappningsregler och tidsstämpelprioritet

Tillämpa en femstegs mappnings- och tidsstämpelprioritetsregeluppsättning för att generera en enda kanonisk ankomsttidslinje för varje fartyg och försändelse: mappa råa händelser till kanoniska faser, välj den högsta prioritetens tidsstämpel för varje fas, bifoga källans tillförlitlighet, och markera konflikter för mänsklig granskning.

Definiera kanoniska faser som: ankomst (fartyg inom 24 NM från hamnen), pilotombord, vid kaj/förtöjd, starta lastoperationer (mottagande av första containerflytt), slutföra lastoperationer, och avgått. Mappa källhändelser till dessa faser: AIS positionsrapporter, manifest från lots/hamnmyndighet, terminaloperativt system (TOS) förtöjningshändelser, rederioperationella meddelanden (SOC/COC), gate-in/gate-out container-skanningar och fartygsdagboksanteckningar. Lagra en kanonisk tidsstämpel per fas och behåll ursprungliga händelselistor för revision och avstämning.

Tidsstämpelprioritet (högst till lägst): 1 – Hamnmyndighetens / lotsens tidsstämplar för pilotOmbord och kajtillstånd (auktoritativa). 2 – Terminaloperativa systemets tidsstämplar för vid kaj/förtöjd och starta lastoperationer. 3 – Terminal-/containergate-skanningar för mottagande och containerflytt. 4 – Rederiets operativa meddelanden (ETA/ATA, SOC/COC) för planerade och operatörsbekräftade milstolpar. 5 – AIS-baserade tidsstämplar (position som passerar X-NM, stoppad vid kaj) för automatisk detektering. Normalisera alltid till UTC ISO 8601 och bifoga källidentifikation och konfidenspoäng.

Lös konflikter med deterministiska regler: om en tidsstämpel med högre prioritet finns, använd den för den kanoniska fasen. Om data med lägre prioritet föregår en tidsstämpel med högre prioritet med mer än tröskel T1 = 30 minuter för kaj/vid kaj eller T2 = 120 minuter för ankomst/ETA, behåll båda tidsstämplarna, markera den kanoniska fasen som "misstänkt", och sätt sourceConfidence = låg. Om AIS indikerar vid kaj tidigare än TOS med <30 minuter, föredra TOS men registrera AIS som stödjande bevis. För saknade data med högre prioritet, befordra nästa tillgängliga källa men registrera en promotionReason och expectedAccuracy (%) baserat på källtyp.

Implementera kontroll av klocka och tidszon: kräva att alla källor skickar tidsstämplar i UTC. För känd klockavvikelse, tillämpa källspecifika förskjutningar beräknade från historiska jämförelser (lagra last-offset och stdev). Avvisa tidsstämplar äldre än 7 dagar för ankomstfaser om de inte åtföljs av ett undertecknat hamnmyndighetsprotokoll. Tillämpa en maximal korrigering på 60 minuter automatiskt; större korrigeringar kräver manuell granskning.

Rekommenderat kanoniskt händelseschema (exempel på fält): eventType, canonicalTimestampUTC, sourceType, sourceId, sourceConfidence(0-1), rawTimestamps[listor], berthId, portUNLocode, vesselIMO, containerCount, affectedContainers[], phaseDurationMinutes. Använd dessa fält för att producera KPI-resultat som minskning av ETA-varians, tidigare kundnotifikationer och mätbar flytttid per container.

Operativ vägledning för adoptörer och allianser: integrera dessa regler i rederi- och terminal-API:er för att möjliggöra konsekventa meddelanden genom DCSA-anpassade slutpunkter. Dela befordrade regler med avsändare och kunder så att system kan expandera automatiserade arbetsflöden och optimera kajplanering. Spåra fem adoptionsmätvärden: procent av faser med auktoritativ källa, genomsnittlig befordringsfrekvens, procent av misstänkta flaggor lösta inom 24 timmar, genomsnittlig avvikelse mellan kanonisk och rederiets ETA, och minskning av tidiga/sena meddelanden. Digitalisering av dessa mappningar kommer att öka synligheten inom olika branscher, hjälpa till att optimera containerflyttar och flytta branschen bortom fragmenterade tidsstämplar så att rederier, terminaler och avsändare får tidigare, mer tillförlitlig försändelseinformation tillsammans med container-nivåns kvitton och resultat.

Validera identifierare för rederier och containrar före inmatning: kontrollsiffror, kodlistor och avvisningshantering

Validera container nummer och rederikoder vid API-gatewayen med hjälp av ISO 6346 kontrollsifferlogik och auktoritativa kodlistor före någon nedströmsinmatning.

Exakt containerformat och kontrollsifferverifiering
- Acceptera endast 11-teckniga ISO 6346-poster: ägarkod (3 bokstäver) + utrustningskategori (1 bokstav, vanligtvis U/J/Z) + serienummer (6 siffror) + kontrollsiffra (1 siffra).
- Beräkna kontrollsiffran: mappa bokstäver till numeriska värden (A=10, B=12, C=13 ... Z=38 med luckor vid 11, 22, 33), multiplicera varje teckenvärde med 2^position (position 0 för första tecknet), summera, ta summan mod 11; om resten = 10 sätt kontrollsiffran = 0. Avvisa omedelbart vid avvikelse.
- Avvisa poster med fel längd, icke-ASCII-bokstäver, inledande nollor i ägarkoden, eller serienummer utanför 000001–999999; logga exakt felorsak och källa (API-anrops-ID eller kalkylbladsrad).
Validering av rederikod och hantering av kodlistor
- Mappa rederiidentifikatorer mot ett auktoritativt register (BIC för ägare, SCAC för amerikanska operationer eller din överenskomna rederilista). Behandla okända koder som karantän tills de lösts.
- Implementera realtidsuppslag när internetåtkomst är tillgänglig; använd en signerad, tidsstämplad cachad ögonblicksbild som reserv om offline. Tillåt cachad giltighet för ett konfigurerbart fönster (standard 24–72 timmar) och registrera ögonblicksbildens version i varje händelse.
- Tillämpa mappning för allianser och fartygsoperativa partners: upprätthåll en kanonisk rederi-till-operativt-rederi-tabell som används av APMS och nedströmsystem; uppdatera mappningen vid varje alliansförändring och registrera vem som tillämpade åsidosättningen.
Kontroller före inmatning för kalkylblad och bulkbelastningar
- Tillhandahåll en klient-sidig validator (Excel-makro eller lättviktig JS) som markerar rader före uppladdning och returnerar en CSV med avvisade rader med felkoder; detta minskar manuella korrigeringar och påskyndar digitalisering av äldre kalkylblad.
- För bulk-inmatning, kör en snabb förhandsgranskning som separerar giltiga, mjukt avvisade (okänt rederi) och hårt avvisade (kontrollsifferavvikelse) rader. Mata endast in giltiga rader; returnera en strukturerad avvisningsfil som avsändaren kan ladda upp igen efter korrigeringar.
Policy för avvisningshantering och fel-taxonomi
1. Använd standardiserade felkoder så att integrationer kan agera automatiskt:
  - ERR01 – FORMAT_OGILTIGT (längd/teckenuppsättning)
  - ERR02 – KONTROLLSIFFER_AVVIKELSE
  - ERR03 – REDERI_OKÄNT
  - ERR04 – MAPPNINGS_ÅSIKTSÄNDRING_KRÄVS
2. Definiera automatiska åtgärder per kod:
  - ERR02: hårt avvisa, meddela avsändaren, blockera tills korrigerat.
  - ERR03: mjuk karantän, försök slå upp från alternativa tjänster i upp till 24 timmar, eskaler sedan till rederiets drift om fortfarande olöst.
  - ERR04: acceptera endast med signerad åsikt från auktoriserad användare; registrera revisionsspår.
Övervakning, KPI:er och SLA:er
- Spåra avvisningsgrad, genomsnittlig tid för åtgärd (MTTR) och andel karantänbehandlade poster som lösts inom SLA. Mål: avvisningsgrad <0,1 % av inmatningsvolymen och MTTR <4 timmar för operativa hamnar/ankomster.
- Instrumentera kontrollpaneler som visar trender och detektering av toppar så att driftpersonal snabbare än manuell granskning kan upptäcka ändringar i rederilistor eller massiva kalkylbladsfel.
Integrationspunkter och operativa skyddsåtgärder
- Validera innan data skickas till tull, APMS, bränsle- och bunkeringssystem. Felaktiga ID:n orsakar faktureringsavvikelser (bränsle), tullförseningar och feldirigerade ankomster.
- När ett externt system (APMS, terminalsystem) skickar uppdateringar, bifoga valideringsögonblicksbildens version så att mottagare vet vilken kodlista som producerade beslutet.
- Använd säkra internet- eller L-bands satellitlänkar där landanslutning är opålitlig; offline-validering måste fortfarande registrera den cachade listans ID tills internetsynkroniseringen är klar.
Styrning, uppdateringar och utvecklingsmetoder
- Automatisera nattliga kodlist-nedladdningar och tillåt manuell forcering för omedelbara ändringar; logga vem som utförde manuella uppdateringar och varför. Meddela nedströms team om ändringar som påverkar rederimappningar eller specifikationer.
- Inkludera enhetstester för kontrollsifferlogik i CI/CD och ett arkiv med verkliga testvektorer (giltiga och ogiltiga nummer) som används under utveckling och QA.
- Underhåll en publik ändringslogg så att partners vet när dina valideringsregler eller listor har ändrats; länka ändringsloggens ID i händelsemeta-data för spårbarhet (se mappning här för de senaste 30 uppdateringarna).
Operativa exempel
- Scenario: en kalkylbladsöverföring från en agent skickar för närvarande 5 000 rader. Kör en förhandsgranskning: 4 990 giltiga, 8 ERR02, 2 ERR03. Returnera en avvisnings-CSV med rad-ID:n, felkoder och föreslagna korrigeringar; mata omedelbart in de 4 990 för att uppfylla ankomsttidsfristerna.
- Scenario: en rederallians ändrar prefix över natten. Tillämpa åsiktförändring, kör avstämning mot fångade ankomster de senaste 48 timmarna, och rulla ut ett korrigerat flöde till tull- och eBOL-system för att undvika nedströmsavvikelser.
Praktisk checklista att implementera idag
1. Driftsätt validering av kontrollsiffror vid API-kanten.
2. Integrera ett auktoritativt kodregister med realtids- och cachade lägen.
3. Skapa mallar för avvisnings-CSV för kalkylbladsanvändare och automatisera förhandsgranskning i uppladdningsgränssnittet.
4. Ställ in KPI-varningar för avvisningsspikar och behåll revisionsspår för alla manuella listuppdateringar.

Att följa dessa steg minskar falska positiva, snabbar upp bearbetningen av ankomster, synkroniserar data med tull- och APMS-flöden, förbättrar bränsle-/faktureringsnoggrannheten och gör det möjligt för dina team att uppnå konsekvent, granskbar inmatning samtidigt som de fortfarande rymmer verkliga operativa ändringar och alliansdrivna mappningar.

Autentisera och anslut till DCSA-tjänster: OAuth-flöden, API-nycklar och sandbox-till-produktion-steg

Använd OAuth 2.0 klientuppgifter för maskin-till-maskin-integrationer och Auktorisationskod med PKCE för alla applikationer som agerar på uppdrag av en användare; lagra klienthemligheter i en hemlighetshanterare och begränsa omfånget till det minsta som krävs.

Kräv TLS 1.2+ för alla anrop över internet, validera certifikat och genomdriv TLS pinning för mobilappar. För publika klienter, implementera PKCE och kortlivade åtkomsttokens med uppdateringstokens som roteras vid första användningen; för konfidentiella klienter föredra mutual TLS om leverantören stöder det.

Registrera varje applikation i DCSA-utvecklarportalen med ett unikt client_id och en miljöspecifik hemlighet eller nyckel. Använd sandbox-uppgifter för utveckling och testning, tagga tester som berör ebls eller tullflöden, och dokumentera vilka API-versioner din integration anropar så att du kan få klarhet om brytande ändringar.

När du får sandbox-tokens, automatisera token-caching och förnyelse: begär en ny token vid 90 % av token-livslängden, försök igen misslyckade token-utbyten med exponentiell backoff, och logga token-fel till en säker revisionsström istället för att skriva ut hemligheter till konsolen. En intelligent lokal proxy som infogar tokens och genomdriver hastighetsbegränsningar minskar utvecklingsfriktionen.

Använd API-nycklar endast för lågrisk telemetri eller partneridentifiering där OAuth inte är tillgängligt; använd aldrig API-nycklar som en ersättning för användarautentisering. Behandla API-nycklar som hemligheter, rotera dem kvartalsvis och blockera nycklar som visar anomalistiska anropsmönster.

Följ denna checklista från sandbox till produktion: 1) slutför kontrakt och DCSA-introduktion, 2) klara säkerhets- och API-överensstämmelsetester i sandbox, 3) tillhandahåll en produktionssupportkontakt och SLA, 4) presentera revisionsloggar och en manuell återställningsplan, 5) skicka in mTLS-certifikat om det krävs, och 6) schemalägg ett produktionsbytefönster med rederier och partners. Om ett rederi som hapag-lloyd eller en tullportal kräver ett oktober-driftsättningsfönster, samordna tidigt och bekräfta vem som skickar slutliga bekräftelsekvitton.

Instrumentera varje produktionsanrop med korrelations-ID:n, spåra förfrågnings-/svarstider, och fånga HTTP-status och affärsnivåkvitton för EDI-ekvivalenta flöden som ebls och bokningsbekräftelser. Tagga händelser efter partner, avsändare, rederi och operativ plats så att nedströms team kan filtrera efter tull-, miljörapporterings- eller bränslestrackeringskrav.

Håll migrationsmanuella steg minimala: automatisera certifikatöverföring, klientregistrering och omfångsgodkännanden där det är möjligt, och upprätthåll en checklista som visar vilka partners som är anslutna och vilka som fortfarande kräver manuell introduktion. Ett enda automatiserat röktest som frågar en bokning och validerar ett spårat kvitto minskar bytesrisken.

Under utvecklingen, emulera partnerbeteende: bygg en stub som skickar realistiska webhook-nyttolaster och validerar dina bekräftelser, inklusive acceptans av ebls och kvittomeddelanden. Kör belastningstester mot sandbox som simulerar toppoperativ trafik från rederier, avsändare och tullportaler så att du kan finjustera återförsök och samtidighet.

Övervaka användning och affärs-KPI:er efter produktionsstart: spåra token-utbytesfrekvens, misslyckade autentiseringsanrop, genomsnittlig anropslatens, och antalet kvitton som inte levererats till partners. Använd dessa mätvärden för att prioritera korrigeringar som direkt påverkar avsändare, rederier och branscher som förlitar sig på tidiga EDI/EBL-uppdateringar och miljö- eller bränslerapportering.