> ## Documentation Index
> Fetch the complete documentation index at: https://proxy-docs.permify.co/llms.txt
> Use this file to discover all available pages before exploring further.
# Write Bundle
## What is Data Bundles?
Ensuring that authorization data remains in sync with the business model is an important practice when using Permify.
Prior to Data Bundles, it was the responsibility of the services (such as [WriteData API](../data/write-data)) to structure how relations are created and deleted when actions occur on resources.
With the Data Bundles, you be able to bundle and model the creation and deletion of relations and attributes when specific actions occur on resources in your applications.
We believe this functionality will streamline managing authorization data as well as managing this in a central place increases visibility around certain actions/triggers that end up with data creation.
## How Bundles Work
Let's examine how Bundles operate with a basic example.
Let's say you want to model how data will be created when an organization is created in your application. For this purpose, you can utilize the WriteBundle API endpoint. This API enables users to define or update data bundles, each distinguished by a unique name.
Here's an example body for WriteBundle in this scenario:
```json theme={null}
"bundles": [
{
"name": "organization_created"
"arguments": [
"creatorID",
"organizationID"
],
"operations": [
{
"relationships_write": [
"organization:{{.organizationID}}#admin@user:{{.creatorID}}",
"organization:{{.organizationID}}#manager@user:{{.creatorID}}",
],
"attributes_write": [
"organization:{{.organizationID}}$public|boolean:false",
],
},
],
},
],
```
Operations represent actions that can be performed on relationships and attributes, such as adding or deleting relationships when certain events occur.
Let's say user:564 creates an organization:789 in your application. According to your authorization logic, this will result in the creation of several authorization data, including relational tuples and attributes, respectively.
* organization:789#admin\@user:564
* organization:789#manager\@user:564
* organization:789\$public|boolean:false
Instead of using the [WriteData](./api-overview/data/write-data.md) endpoint, you can utilize [RunBundle](./api-overview/data/run-bundle.md) to create this data by simply providing specific identifiers.
An example request of [RunBundle](./api-overview/data/run-bundle.md) for this scenario:
```json theme={null}
POST /bundle
BODY
{
"name": "project_created",
"arguments": {
"creatorID": "564",
"organizationID": "789",
}
}
```
This will result in the creation of the following data in Permify:
* organization:789#admin\@user:564
* organization:789#manager\@user:564
* organization:789\$public|boolean:false
## Endpoints
* [WriteBundle](./write-bundle)
* [RunBundle](../data/run-bundle)
* [DeleteBundle](./delete-bundle)
* [ReadBundle](./read-bundle)
## Write Bundles Request
The "Write Bundle" API is designed for handling data in a multi-tenant application environment. Its primary function is to write and delete data according to predefined structures. This API allows users to define or update data bundles, each distinguished by a unique name.
## OpenAPI
````yaml post /v1/tenants/{tenant_id}/bundle/write
openapi: 3.0.0
info:
title: Permify API
description: >-
Permify is an open source authorization service for creating fine-grained
and scalable authorization systems.
version: v1.6.10
contact:
name: API Support
url: https://github.com/Permify/permify/issues
email: hello@permify.co
license:
name: AGPL-3.0 license
url: https://github.com/Permify/permify/blob/master/LICENSE
servers: []
security: []
tags:
- name: Permission
- name: Watch
- name: Schema
- name: Data
- name: Bundle
- name: Tenancy
paths:
/v1/tenants/{tenant_id}/bundle/write:
post:
tags:
- Bundle
summary: write bundle
operationId: bundle.write
parameters:
- name: tenant_id
description: >-
Identifier of the tenant, if you are not using multi-tenancy (have
only one tenant) use pre-inserted tenant t1 for this
field. Required, and must match the pattern \“[a-zA-Z0-9-,]+\“, max
64 bytes.
in: path
required: true
schema:
type: string
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/Bundle.WriteBody'
required: true
responses:
'200':
description: A successful response.
content:
application/json:
schema:
$ref: '#/components/schemas/BundleWriteResponse'
default:
description: An unexpected error response.
content:
application/json:
schema:
$ref: '#/components/schemas/Status'
x-codeSamples:
- label: go
lang: go
source: >-
rr, err := client.Bundle.Write(context.Background(),
&v1.BundleWriteRequest{
TenantId: "t1",
Bundles: []*v1.DataBundle{
{
Name: "organization_created",
Arguments: []string{
"creatorID",
"organizationID",
},
Operations: []*v1.Operation{
{
RelationshipsWrite: []string{
"organization:{{.organizationID}}#admin@user:{{.creatorID}}",
"organization:{{.organizationID}}#manager@user:{{.creatorID}}",
},
AttributesWrite: []string{
"organization:{{.organizationID}}$public|boolean:false",
},
},
},
},
},
})
- label: node
lang: javascript
source: |-
client.bundle.write({
tenantId: "t1",
bundles: [
{
name: "organization_created",
arguments: [
"creatorID",
"organizationID",
],
operations: [
{
relationships_write: [
"organization:{{.organizationID}}#admin@user:{{.creatorID}}",
"organization:{{.organizationID}}#manager@user:{{.creatorID}}",
],
attributes_write: [
"organization:{{.organizationID}}$public|boolean:false",
]
}
]
}
]
}).then((response) => {
// handle response
})
- label: cURL
lang: curl
source: >-
curl --location --request POST
'localhost:3476/v1/tenants/{tenant_id}/bundle/write' \
--header 'Content-Type: application/json' \
--data-raw '{
"bundles": [
{
"name": "organization_created",
"arguments": [
"creatorID",
"organizationID"
],
"operations": [
{
"relationships_write": [
"organization:{{.organizationID}}#admin@user:{{.creatorID}}",
"organization:{{.organizationID}}#manager@user:{{.creatorID}}"
],
"attributes_write": [
"organization:{{.organizationID}}$public|boolean:false"
]
}
]
}
]
}'
components:
schemas:
Bundle.WriteBody:
type: object
properties:
bundles:
type: array
items:
$ref: '#/components/schemas/DataBundle'
description: Contains the bundle data to be written.
description: |-
BundleWriteRequest is used to request the writing of a bundle.
It contains the tenant_id to identify the tenant and the Bundles object.
BundleWriteResponse:
type: object
properties:
names:
type: array
items:
type: string
description: Identifier or acknowledgment of the written bundle.
description: >-
BundleWriteResponse is the response for a BundleWriteRequest.
It includes a name which could be used as an identifier or
acknowledgment.
Status:
type: object
properties:
code:
type: integer
format: int32
message:
type: string
details:
type: array
items:
$ref: '#/components/schemas/Any'
DataBundle:
type: object
properties:
name:
type: string
description: >-
'name' is a simple string field representing the name of the
DataBundle.
arguments:
type: array
items:
type: string
description: >-
'arguments' is a repeated field, which means it can contain multiple
strings.
These are used to store a list of arguments related to the
DataBundle.
operations:
type: array
items:
$ref: '#/components/schemas/v1.Operation'
description: >-
'operations' is a repeated field containing multiple Operation
messages.
Each Operation represents a specific action or set of actions to be
performed.
description: >-
DataBundle is a message representing a bundle of data, which includes a
name,
a list of arguments, and a series of operations.
Any:
type: object
properties:
'@type':
type: string
description: >-
A URL/resource name that uniquely identifies the type of the
serialized
protocol buffer message. This string must contain at least
one "/" character. The last segment of the URL's path must represent
the fully qualified name of the type (as in
`path/google.protobuf.Duration`). The name should be in a canonical
form
(e.g., leading "." is not accepted).
In practice, teams usually precompile into the binary all types that
they
expect it to use in the context of Any. However, for URLs which use
the
scheme `http`, `https`, or no scheme, one can optionally set up a
type
server that maps type URLs to message definitions as follows:
* If no scheme is provided, `https` is assumed.
* An HTTP GET on the URL must yield a [google.protobuf.Type][]
value in binary format, or produce an error.
* Applications are allowed to cache lookup results based on the
URL, or have them precompiled into a binary to avoid any
lookup. Therefore, binary compatibility needs to be preserved
on changes to types. (Use versioned type names to manage
breaking changes.)
Note: this functionality is not currently available in the official
protobuf release, and it is not used for type URLs beginning with
type.googleapis.com. As of May 2023, there are no widely used type
server
implementations and no plans to implement one.
Schemes other than `http`, `https` (or the empty scheme) might be
used with implementation specific semantics.
additionalProperties: {}
description: >-
`Any` contains an arbitrary serialized protocol buffer message along
with a
URL that describes the type of the serialized message.
Protobuf library provides support to pack/unpack Any values in the form
of utility functions or additional generated methods of the Any type.
Example 1: Pack and unpack a message in C++.
Foo foo = ...;
Any any;
any.PackFrom(foo);
...
if (any.UnpackTo(&foo)) {
...
}
Example 2: Pack and unpack a message in Java.
Foo foo = ...;
Any any = Any.pack(foo);
...
if (any.is(Foo.class)) {
foo = any.unpack(Foo.class);
}
// or ...
if (any.isSameTypeAs(Foo.getDefaultInstance())) {
foo = any.unpack(Foo.getDefaultInstance());
}
Example 3: Pack and unpack a message in Python.
foo = Foo(...)
any = Any()
any.Pack(foo)
...
if any.Is(Foo.DESCRIPTOR):
any.Unpack(foo)
...
Example 4: Pack and unpack a message in Go
foo := &pb.Foo{...}
any, err := anypb.New(foo)
if err != nil {
...
}
...
foo := &pb.Foo{}
if err := any.UnmarshalTo(foo); err != nil {
...
}
The pack methods provided by protobuf library will by default use
'type.googleapis.com/full.type.name' as the type URL and the unpack
methods only use the fully qualified type name after the last '/'
in the type URL, for example "foo.bar.com/x/y.z" will yield type
name "y.z".
JSON
====
The JSON representation of an `Any` value uses the regular
representation of the deserialized, embedded message, with an
additional field `@type` which contains the type URL. Example:
package google.profile;
message Person {
string first_name = 1;
string last_name = 2;
}
{
"@type": "type.googleapis.com/google.profile.Person",
"firstName": ,
"lastName":
}
If the embedded message type is well-known and has a custom JSON
representation, that representation will be embedded adding a field
`value` which holds the custom JSON in addition to the `@type`
field. Example (for message [google.protobuf.Duration][]):
{
"@type": "type.googleapis.com/google.protobuf.Duration",
"value": "1.212s"
}
v1.Operation:
type: object
properties:
relationships_write:
type: array
items:
type: string
description: >-
'relationships_write' is a repeated string field for storing
relationship keys
that are to be written or created.
relationships_delete:
type: array
items:
type: string
description: >-
'relationships_delete' is a repeated string field for storing
relationship keys
that are to be deleted or removed.
attributes_write:
type: array
items:
type: string
description: >-
'attributes_write' is a repeated string field for storing attribute
keys
that are to be written or created.
attributes_delete:
type: array
items:
type: string
description: >-
'attributes_delete' is a repeated string field for storing attribute
keys
that are to be deleted or removed.
description: >-
Operation is a message representing a series of operations that can be
performed.
It includes fields for writing and deleting relationships and
attributes.
````