Een koppeling die vandaag werkt, kan over een jaar stilvallen zonder dat iemand iets heeft aangepast. Salesforce trekt de stekker uit de OAuth 2.0 username-password flow voor connected apps: een integratie die authenticeert met grant_type=password krijgt daarna geen access token meer. Er komt geen waarschuwing in de interface aan te pas. Dat raakt precies het soort koppelingen dat wij dagelijks zien, tussen Salesforce en een boekhoud- of ERP-pakket.

Wat er verandert en wanneer

Salesforce handhaaft deze release update op 20 februari 2027. Die datum is aangepast: oorspronkelijk zou de handhaving met de Winter ’27-release meekomen, maar Salesforce heeft hem losgekoppeld van het releaseweekend van uw org. U heeft dus een vaste datum om naartoe te werken, en niet een datum die per org verschilt.

Twee dingen gelden nu al wel:

  • In orgs die vanaf Summer ’26 zijn aangemaakt is de flow helemaal niet meer te gebruiken.
  • Op de pagina OAuth and OpenID Connect Settings is de optie om OAuth username-password flows toe te staan uitgegrijsd.

Daarnaast loopt er een tweede traject dat dezelfde koppelingen raakt. De SOAP API login()-call in API-versies 31.0 tot en met 64.0 vervalt met de Summer ’27-release, en in versie 65.0 en hoger bestaat hij al niet meer. In orgs die vanaf Winter ’26 zijn aangemaakt staat hij standaard uit. Waar hij nog aanstaat, heeft een gebruiker het recht Use Any API Auth nodig om te kunnen authenticeren; zonder dat recht komt er een INSUFFICIENT_ACCESS-fout terug.

Hoe u achterhaalt welke koppelingen dit raakt

U hoeft dit niet op gevoel te doen. Ga in Setup naar Login History en maak een eigen lijstweergave met Login Subtype als filter. Dat veld laat per login zien via welke OAuth-flow een connected app binnenkwam, waaronder de username-password flow. De pagina bewaart zes maanden aan logins en is als CSV te downloaden, dus u ziet in één keer of er nog verkeer op de oude flow zit.

Voor de SOAP-kant zoekt u in dezelfde Login History naar regels met:

  • Login Type “Other Apex API” of “Partner Product”;
  • Login Subtype “SOAP API”;
  • API Type “SOAP Enterprise”, “SOAP Partner” of “SOAP Tooling”.

Staat er bij zo’n regel “N/A” in het veld Application, dan ontbreken er geen gegevens. Dat is precies het teken dat de client niet aan een connected app hangt, en dus tot de groep hoort die moet migreren. Via het veld Username achterhaalt u welk serviceaccount het betreft, en daarmee welke applicatie erachter zit. Wilt u dieper kijken, dan geeft de API Total Usage EventLogFile de bijbehorende API-aanroepen: standaard over de afgelopen 24 uur, en met Event Monitoring over dertig dagen.

Waar u naartoe migreert

Salesforce wijst twee routes aan. Voor server-naar-server-integraties, het merendeel van de koppelingen met een boekhoudpakket, is dat de OAuth 2.0 client credentials flow. Draait de koppeling op naam van een ingelogde gebruiker, dan is de web server flow met de PKCE-extensie de aangewezen weg. Vervangt u een SOAP login(), dan is naast client credentials ook de JWT bearer flow een optie.

Bouwde u de koppeling zelf, dan is dit uw werk. Komt hij van een leverancier, vraag dan nu welke versie de nieuwe flows ondersteunt in plaats van in februari 2027. Hoe zulke koppelingen in elkaar zitten, leest u in ons stuk over de Salesforce API en maatwerk-integraties en in het overzicht van Salesforce connectors.

Wilt u laten nakijken welke van uw integraties op de oude authenticatie draaien en wat het migreren kost? Onze consultancy loopt uw connected apps en serviceaccounts langs en legt vast wat er voor 20 februari 2027 om moet. Neem contact met ons op en we plannen het in.