---
title: "Metadata Document"
method: GET
path: "/v1/projects/{projectId}/forms/{xmlFormId}.svc/$metadata"
tags: ["OData Form Service"]
---

# Metadata Document

`GET /v1/projects/{projectId}/forms/{xmlFormId}.svc/$metadata`

The Metadata Document describes, in [EDMX CSDL](http://docs.oasis-open.org/odata/odata-csdl-xml/v4.01/odata-csdl-xml-v4.01.html), the schema of all the data you can retrieve from the OData Form Service in question. This is essentially the XForms form schema translated into the OData format. EDMX/CSDL defines schemas in terms of objects, their properties, and relationships to other objects.

If you are writing a tool to analyze your own data, whose schema you already know and understand, there is very little reason to touch this endpoint. You can likely skip ahead to the data documents themselves and work directly with the simple JSON output returned by those endpoints. This endpoint is more useful for authors of tools which seek to generically work with arbitrary data whose schemas they cannot know in advance.

In general, the way we model the XForms schema in OData terms is to represent `group`s as `ComplexType`s, and `repeat`s as `EntityType`s. In the world of OData, the primary difference between these two types is that Entity Types require Primary Keys, while Complex Types do not. This fits well with the way XForms surveys tend to be structured.

Most other types map to `String`. The exceptions are numbers, which map either to `Int64` or `Decimal` as appropriate, datetime fields which are always `DateTimeOffset`, date fields which become `Date`, and geography points which will appear as `GeographyPoint`, `GeographyLineString`, or `GeographyPolygon` given a `geopoint`, `geotrace`, or `geoshape`.

We also advertise the relationships between tables (the point at which a `repeat` connects the parent data to the repeated subtable) using the `NavigationProperty`. This should allow clients to present the data in an interconnected way, without the user having to specify how the tables connect to each other.

This implementation of the OData standard includes a set of Annotations describing the supported features of the service in the form of the [Capabilities Vocabulary](https://github.com/oasis-tcs/odata-vocabularies/blob/master/vocabularies/Org.OData.Capabilities.V1.md). In general, however, you can assume that the server supports the Minimal Conformance level and nothing beyond.

While the latest 4.01 OData specification adds a new JSON EDMX CSDL format, most servers and clients do not yet support that format, and so for this release of ODK Central only the older XML EDMX CSDL format is available.

## Path parameters

- `projectId` number, required
- `xmlFormId` string, required

## Response `200`

OK

## Other responses

- `406` — Not Acceptable

## Changes

- **2025-12-20** `022694254f0d` — 1 info
  - api operation id `Metadata Document` removed and replaced with `metadataDocument`
- **2025-10-27** `b11b54eea487` — 1 info
  - removed the non-success response with the status `403`
- **2025-03-13** `e8c2858fd4eb` — 2 info
  - api operation id `metadataDocument` removed and replaced with `Metadata Document`
  - added the non-success response with the status `403`

[Change history](https://skmtc.dev/getodk/apis/odk-central-api/changes/v1/projects/:projectId/forms/:xmlFormId.svc/$metadata/get.md)

---

[API](https://skmtc.dev/getodk/apis/odk-central-api.md) · [All operations](https://skmtc.dev/getodk/apis/odk-central-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/getodk/odk-central-api/revisions/d4f5ba77f644/schema)