finautapi package¶
Module contents¶
Subpackages¶
- finautapi.api package
- Module contents
- Submodules
- finautapi.api.companies module
- finautapi.api.competency_plan module
- finautapi.api.competency_result module
- finautapi.api.departments module
- finautapi.api.employment module
- finautapi.api.exceptions module
- finautapi.api.finaut_auth_required module
- finautapi.api.franchises module
- finautapi.api.goals module
- finautapi.api.mixins module
- finautapi.api.ordninger module
- finautapi.api.results module
- finautapi.api.training_result module
- finautapi.api.userrole module
- finautapi.api.users module
- finautapi.api.userstatus module
- finautapi.api.utils module
- finautapi.api.validators module
- finautapi.jobs package
- finautapi.management package
Submodules¶
finautapi.admin module¶
finautapi.apps module¶
finautapi.decorators module¶
finautapi decorators
- finautapi.decorators.finaut_token_user(fn)¶
Fetch user from oauth application and attach it to token.
finautapi.finautapi_middleware module¶
finautapi.models module¶
finautapi.permissions module¶
finautapi.schemas module¶
Which API docs the site serves.
DRF 3.17 (the py3.12 tier) removed CoreAPI, and with it the
interactive docs norsktest_api serves at docs/ on py3.11. Where
CoreAPI is gone or off, docs/ is drf-spectacular’s Swagger UI
instead, at the same url, so the client instructions keep working.
DRF has deprecated its own OpenAPI generation in favour of
drf-spectacular, so that is what builds the schema too.
Nothing here imports drf-spectacular: a py3.11 site in CoreAPI mode never needs it. The site configures it (norsktest_api/settings.py).
- finautapi.schemas.coreapi_mode()¶
Does this site still serve CoreAPI schemas (DRF < 3.17)?
Imported on call, not at module load, so a DRF without CoreAPI is seen whenever it is asked.
finautapi.signals module¶
finautapi.urls module¶
finautapi.views module¶
finautapi.webhooks module¶
Asynchronous delivery of finautapi webhooks.
WebHook.process_data (models.py) decides which webhooks a saved
record should reach and serializes the payload inside the request.
The HTTP POST itself is handed to the dkdramatiq worker through
schedule_delivery(), so a slow customer endpoint never holds a
gunicorn worker – or the transaction the signal runs in – hostage.
deliver_webhook() is the function the worker imports by dotted
name (see dkdramatiq.models.Job.process), so it must stay
importable on its own and take JSON-serializable arguments only.
- finautapi.webhooks.DELIVER_FN = 'finautapi.webhooks.deliver_webhook'¶
dotted path the dkdramatiq worker imports
- finautapi.webhooks.WEBHOOK_TIMEOUT = 10¶
seconds to wait for the customer endpoint
- finautapi.webhooks.deliver_webhook(webhook_id, json_data, headers, correlation_id)¶
POST
json_datato the webhook’s target and record a WebHookLog.Runs in the dkdramatiq worker, or inline as a fallback. Errors end up in the log row, they are never raised.
- finautapi.webhooks.schedule_delivery(webhook, json_data, headers, correlation_id)¶
Queue
deliver_webhook()to run once the current transaction has committed.Signal handlers run inside the saving transaction; queueing on commit means a rolled-back save never produces a webhook, and the customer is never told about a record that does not exist.
Falls back to inline delivery when the queue is unavailable (or when
settings.WEBHOOK_SYNC_DELIVERYis set), so a broker outage degrades to the old synchronous behaviour instead of dropping the webhook.