PRP
  • PRP Documentation
  • Introduction
    • Glossary / Terminology
    • Indicators
      • Disaggregations
      • Calculating progress
    • FAQ
    • Releases / Changelog*
    • Report an Issue / Contact us
  • Product / End-user Documentation
    • IP Reporting
      • Overview
      • Partner roles and permissions
      • User Interface
      • Setting calculation methods for indicators
      • Progress Reports
        • Reporting Overview
        • Special Reports (SR)
        • Humanitarian Reports (HR)
        • Quarterly Progress Reports (QPR)
        • Reporting Process
        • Data Uploader for QPR and HR
      • Various data exports
    • Cluster Reporting
      • Overview
      • User Authentication, Roles and permissions
      • AD Integration
      • Response Plans
      • Cluster Indicators
      • Response Plan Dashboard
      • Response Parameters setup
      • Planning your action as a Partner
      • Reporting on results
        • Reporting to UNICEF
      • Analysis of results
      • OCHA Integration
    • ID Management
      • Overview
      • AD Integration & Sign In
      • Email Notifications
      • User Statuses
      • Permissions
      • IP ID Management
        • User Interface
        • Users screen
      • Cluster ID Management
        • User Interface
        • Users screen
        • Partners screen
  • Technical Documentation
    • Architecture
    • Development Setup
    • Deployment / DevOps
    • Data Model
    • API Documentation
      • Error Handling
    • CartoDB location sync
    • OCHA Integration - Research Summary
      • Response Plan Import
      • Project Import
    • ID Management
      • Backend API's
    • Handover session question
Powered by GitBook
On this page
  • General / Non Field Errors
  • Field Errors
  1. Technical Documentation
  2. API Documentation

Error Handling

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

Expected http status codes are 404 and 400. 400 response details have been detailed below.

General / Non Field Errors

A response for a single error would look like this:

{
    "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 related to fields will be returned as a mapping

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

And of course can contain multiple messages per 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 DocumentationNextCartoDB location sync

Last updated 7 years ago