Community

Open Source

Playground

Permify Docs

API References

Support

Read Bundle

`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": <string>,
      "lastName": <string>
    }

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"
    }

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.

DataBundle is a message representing a bundle of data, which includes a name,
a list of arguments, and a series of operations.

'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.

'name' is a simple string field representing the name of the DataBundle.

'operations' is a repeated field containing multiple Operation messages.
Each Operation represents a specific action or set of actions to be performed.

Operation is a message representing a series of operations that can be performed.
It includes fields for writing and deleting relationships and attributes.

'attributes_delete' is a repeated string field for storing attribute keys
that are to be deleted or removed.

'attributes_write' is a repeated string field for storing attribute keys
that are to be written or created.

'relationships_delete' is a repeated string field for storing relationship keys
that are to be deleted or removed.

'relationships_write' is a repeated string field for storing relationship keys
that are to be written or created.

read bundle

Start building scalable and fine-grained authorization systems in mere minutes.

Explore Permify

Authorization As A Service

Authorization As A Service | Permify

Permify FAQs

Quickstart

Modeling Authorization

Storing Data & Schema

Interacting With The API

Testing & Validation

Configuration

Data Bundles

Cache Mechanisms

Contextual Permissions

Observability

Consistency (Snap Tokens)

Data Synchronization

Role Based Access Control (RBAC)

Relationship Based Access Control (ReBAC)

Attribute Based Access Control (ABAC)

Custom Roles

Multi Tenancy

LLM Authorization

Upgrade Guide from v1.0 to v1.1

Example section for showcasing API endpoints

Introduction

Write Schema

List Schema

Partial Schema Update

Read Schema

Write Authorization Data

Read Relationships

Read Attributes

Run Bundle

Delete Data

Check Access Control

Expand API

Subject Filtering

Lookup Entity (Data Filtering)

Lookup Entity (Streaming)

Subject Permission List

List Tenants

Create Tenant

Delete Tenant

Write Bundle

Delete Bundle

Watch API

User Groups

Healthcare System

Document Management

Social Network

Fintech & Banking

Organization Tool

Global Roles

Resource Specific Roles

Public or Private Resources

Text & Object Based Conditions

Numerical Conditions

Organization Hierarchies

Inherited/Nested Permissions

Recursive Relationships

Deployment

Deploy on AWS ECS, ECR & EC2

Install with Brew

Run using Docker

Deploy on Fly.io

Deploy on Google Compute Engine

Deploying Permify with Helm Charts

Deploy on Kubernetes Cluster

OpenTelemetry

Jaeger

SigNoz

Zipkin

API Documentation

Schema Service

Data Service

Permission Service

Tenancy Service

Bundle Service

Watch Service

Read Bundle

Path Parameters

Body

Response