> ## Documentation Index > Fetch the complete documentation index at: https://docs.assetinfinity.ai/llms.txt > Use this file to discover all available pages before exploring further. # Create a record of any kind > Create a row of an administered entity, with its custom field answers. Only the supplied keys are written, so the model's defaults still apply to everything else. `p_id` is for the one caller that has to name the row before it exists — a handset attaching a photograph to an asset it is adding in front of the asset. It is an argument and not a payload key, so `id` stays refused on every generic write. ## OpenAPI ````yaml /api-reference/integration.json post /rpc/create_record openapi: 3.0.0 info: description: >- The calls an integration needs first. Every endpoint the application uses is in the complete reference. title: Asset Infinity integration API version: 12.2.3 servers: - url: https://app.assetinfinity.ai/api security: [] tags: - description: >- Exchange an API key, or an email and password, for a short-lived session token, and send it as `Authorization: Bearer ` on every other call. name: Signing in - description: >- Where assets are and work happens. A location belongs to a site and may sit inside another location. name: Sites and locations - description: >- The asset register: read it, add to it, correct it, move an asset between sites and locations, and change its status. name: Assets - description: >- Report a problem. A request is triaged by a person, who turns it into a work order or turns it down. name: Work requests - description: >- Raise a job, give it to somebody, move it through the organisation's statuses, complete it and close it. name: Work orders - description: >- Send readings in. A meter reading brings the meter forward and raises any maintenance the usage has made due. A sensor reading can open or clear an alert. name: Meters and sensors - description: >- The part catalogue and what is on the shelf in each store, and the three movements an outside system most often records: a delivery in, an issue out and a correction. name: Parts and stock - description: >- Have the product call your system when something happens, instead of asking it on a timer. name: Webhooks - description: >- The calls behind every register that has no call of its own, answers to the organisation's own fields, and the two calls that answer what to send. `list_options` returns the ids a field accepts. `describe_call` returns the fields any call takes. name: Any record externalDocs: description: PostgREST Documentation url: https://postgrest.org/en/v12/references/api.html paths: /rpc/create_record: post: tags: - Any record summary: Create a record of any kind description: >- Create a row of an administered entity, with its custom field answers. Only the supplied keys are written, so the model's defaults still apply to everything else. `p_id` is for the one caller that has to name the row before it exists — a handset attaching a photograph to an asset it is adding in front of the asset. It is an argument and not a payload key, so `id` stays refused on every generic write. parameters: - $ref: '#/components/parameters/preferParams' requestBody: content: application/json: schema: description: >- Create a row of an administered entity, with its custom field answers. Only the supplied keys are written, so the model's defaults still apply to everything else. `p_id` is for the one caller that has to name the row before it exists — a handset attaching a photograph to an asset it is adding in front of the asset. It is an argument and not a payload key, so `id` stays refused on every generic write. properties: p_custom_fields: format: jsonb p_entity: format: text type: string p_id: format: uuid type: string p_values: format: jsonb required: - p_entity - p_values type: object application/vnd.pgrst.object+json: schema: description: >- Create a row of an administered entity, with its custom field answers. Only the supplied keys are written, so the model's defaults still apply to everything else. `p_id` is for the one caller that has to name the row before it exists — a handset attaching a photograph to an asset it is adding in front of the asset. It is an argument and not a payload key, so `id` stays refused on every generic write. properties: p_custom_fields: format: jsonb p_entity: format: text type: string p_id: format: uuid type: string p_values: format: jsonb required: - p_entity - p_values type: object application/vnd.pgrst.object+json;nulls=stripped: schema: description: >- Create a row of an administered entity, with its custom field answers. Only the supplied keys are written, so the model's defaults still apply to everything else. `p_id` is for the one caller that has to name the row before it exists — a handset attaching a photograph to an asset it is adding in front of the asset. It is an argument and not a payload key, so `id` stays refused on every generic write. properties: p_custom_fields: format: jsonb p_entity: format: text type: string p_id: format: uuid type: string p_values: format: jsonb required: - p_entity - p_values type: object text/csv: schema: description: >- Create a row of an administered entity, with its custom field answers. Only the supplied keys are written, so the model's defaults still apply to everything else. `p_id` is for the one caller that has to name the row before it exists — a handset attaching a photograph to an asset it is adding in front of the asset. It is an argument and not a payload key, so `id` stays refused on every generic write. properties: p_custom_fields: format: jsonb p_entity: format: text type: string p_id: format: uuid type: string p_values: format: jsonb required: - p_entity - p_values type: object required: true responses: '200': description: OK components: parameters: preferParams: description: Preference in: header name: Prefer required: false schema: enum: - params=single-object type: string ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.