Third Party Monitoring Module
  • Third Party Monitoring Module Documentation
  • INTRODUCTION
    • Glossary / Terminology
    • FAQ
    • Releases / Changelog*
    • Report an Issue / Contact us
  • PRODUCT / END-USER DOCUMENTATION
    • Overview
      • User rights and permissions
    • Third Party Monitoring Module Navigation
    • Overall User Interface
    • Third Party Monitors section
      • List of Third Party Monitors
      • TPM partner details screen
    • List of Visits section
      • List of Visits
      • Visit details
      • Statuses and corresponding actions
        • Draft
        • Assigned
        • TPM Accepted
        • TPM Rejected
        • Cancelled
        • TPM Reported
        • Sent Back to TPM
        • UNICEF Approved
      • Emails notifications flow
    • TPM workflow
  • TECHNICAL DOCUMENTATION
    • Architecture
    • Development Setup
    • Deployment / DevOps
    • Backend Module structure
    • Data Model
    • Fixtures & management commands
    • API Documentation
      • Error Handling
    • Synchronization with VISION
    • Permissions framework
    • FSM Transitions conditions
    • FSM Transitions in view
    • API Metadata
    • Serializer Mixins
    • Model Mixins
    • Tests
    • Attachments
    • Email links & Tokens Authorization
    • Frontend
      • Module structure
      • Build process
      • Tests
Powered by GitBook
On this page
  1. TECHNICAL DOCUMENTATION
  2. API Documentation

Error Handling

Original Django Rest Framework has been modified a bit for consistency and extended in order to include error codes.

Expected http status codes are 404 and 400. 400 response details are presented below:

General / Non Field Errors

A response for a single error looks like the following:

{
    "non_field_errors": [
        "Error message"
    ],
    "error_codes": [
        "invalid"
    ]
}

Multiple errors can be provided under non_field_errors key, eg.:

{
    "non_field_errors": [
        "Error message",
        "Another error"
    ],
    "error_codes": [
        "invalid",
        "invalid"
    ]
}

Field Errors

Errors, associated with the fields, will be returned as a mapping:

{
    "email": [
        "This field is required."
    ],
    "error_codes": {
        "email": [
            "required"
        ]
    }
}

And of course can contain multiple messages for a single field:

{
    "field1": [
        "Err1",
        "Err2"
    ],
    "field2": [
        "Err3"
    ],
    "error_codes": {
        "field1": [
            "invalid",
            "invalid"
        ],
        "field2": [
            "invalid"
        ]
    }
}

Any exceptions to these rules should be treated as bugs and reported.

PreviousAPI DocumentationNextSynchronization with VISION

Last updated 6 years ago