Meeting 2 - 2018-01-03

Notes

Wisconsin, Michigan, FL CODE and Arizona all presented their error logs (see materials on SIG home page).

For the most part, these indicated large amounts of authorization errors - 403s - and suggested a few issues:

• Low client understanding of authorization in the APIs, and particularly that a client may not have access to a resource it has written unless there is a relationship/role based claim in place (e.g. after POSTing a /student, the student cannot be edited unless the student has been enrolled in a school to which the API client has permissions)
• Clients not taking action after repeated failures, but just continuing to send more requests which would fail
• Excessive synching: some clients seem to re-sync daily, which also increases failures

500 errors only seemed to be a problem in API implementations based on older code-bases.

There were also a fair number of failures on GETs (404s) but those are to be expected given reconciliation processes.

The idea of introducing error codes was briefly discussed, but no clear consensus emerged on if it would be helpful. This is a strategy that Wisconsin is using, however. 

The group also looked at the Wisconsin work around summarizing API integrations data for clients, as a means of trying to help districts and their vendors troubleshoot problems and monitor health of integrations.