20% of Part II — turning inbound API calls into new Okta users.
3 tasks · this deck covers task 3 of 3
↑ Use API Endpoints to Create Users OverviewThis is the same testing mechanic used everywhere else in Workflows — but here it means confirming two things at once: that the API Endpoint card actually receives and parses the caller's payload, and that a real user lands in Okta at the end.
General flow testing — the Run button, adding test data, reading Execution History, testing individual cards — is covered there in depth. This deck adds only the operational angle specific to an API-endpoint-triggered flow.
To test flows during development, "click Run in the toolbar when editing a flow" — the dialog "allows you to add test data to your flow", and "the execution history shows the data as it passes through each card in the flow." For an API-endpoint flow specifically, your test data is the JSON payload an external caller would send — so testing means feeding in a realistic sample payload and checking two card outputs in particular:
→ JSON Parse card — per HTTP Error Codes (Module 1, Sub 3), confirm the response status code was in the 2xx range before trusting the body; then verify Parse produced the object/list type you configured, not a runtime error.
→ Create User card — check Execution History for the returned user ID and Status; per Common Error Messages (Sub 2), an invalid type conversion here usually traces back to a field pulled from the parsed JSON with the wrong shape.
Sources: help.okta.com/wf — connector-builder/test-flows.htm (full deck: Troubleshooting Flows, Module 1)
Next Use Case: Create a Report →