Thanks for the feedback! I see you're working with FoAz (Frontend-only Authorization) . Let me address your points: ​*Important Note*​: FoAz is deprecated and no longer supported, but it is still available at app.permit.io/foaz-proxy (1) (2) (3) . For URL-Based permission, Permit.io is introducing app.permit.io/url-mapping (1) . Regarding your specific concerns: ​*1. Localhost URLs*​: The documentation doesn't explicitly address localhost URL restrictions. This limitation appears to be by design in the FoAz proxy implementation. ​*2. One-to-one mapping limitation*​: You're correct that each URL-method combination maps to a single resource-action pair (3) . The mapping rules are structured into four components: the API endpoint URL, HTTP method, Permit resource, and action . ​*3. Multi-tenancy support*​: For multi-tenant scenarios, you can include the tenant in the permission check. When checking permissions using URL Mapping via the PDP's

/allowed_url

endpoint, you can specify the tenant (1) (2) :

{
  "user": {
    "key": "<mailto:raz@permit.io|raz@permit.io>"
  },
  "url": "<https://example.com/endpoint?param=value>",
  "http_method": "POST",
  "tenant": "default"
}

(1) The fetch request you showed is for the FoAz proxy. For proper multi-tenant support, consider using the PDP directly with the

/allowed_url

endpoint instead of the proxy approach (1) (2) . Given FoAz's deprecated status, I'd recommend migrating to the newer URL Mapping feature or using the PDP directly for better flexibility and ongoing support.

To learn more, see the sources I considered: [[1] Simple URL Mapping Check](https://docs.permit.io/foaz/url-mapping-check) [[2] Regex URL Mapping Check](https://docs.permit.io/foaz/regex-url-mapping-check) [[3] Working with the UI](https://docs.permit.io/foaz/visual-guide)

Screenshot from 2025-11-05 10-47-37.png,Screenshot from 2025-11-05 10-48-33.png

For #2 @Seiichi Arai, The (URL, method) pair is like a translation key between the API request and the internal logic. Each pair must be unique, otherwise the backend wouldn’t know which internal resource or action to trigger.

@Seiichi Arai For #1, I was able to test this in my env and I have a working example via the API. The UI currently has filed validation that won't let you save a non-https or regex based url. Take a look at this guide/tutorial to see how to configure all these: https://deploy-preview-539--permitio-docs.netlify.app/foaz/regex-url-mapping-check/

curl --location '<https://api.permit.io/v2/facts/support/urlmapping/proxy_configs>' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer permit_key_yourKey' \
--data '{
  "secret": "notUsed",
  "key": "test_http",
  "name": "test_http",
  "auth_mechanism": "Bearer",
  "mapping_rules": [
    {
        "url": "^<http://localhost/users/(?P><user_id>[0-9]+)/profile$",
        "http_method": "post",
        "resource": "customers",
        "action": "create",
        "url_type": "regex",
        "priority": "1"
    }
  ]
}'

Note that

user_id

can be used in resource.attribute based ABAC rules (similar to your

tenant

need). Note that the values are mapped to resource.attributes, and so it will show up as

resource.tenant

and not

tenant.id

.

Proof it works: AllowedURL call:

curl --location '<http://localhost:7766/allowed_url>' \
--header 'x-permit-sdk-language: <string>' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer permit_key_yourKey' \
--data '{
  "user": {
    "key": "bob"
  },
  "http_method": "post",
  "url": "<http://localhost/users/123/profile>",
  "tenant": "default"
}'

Response:

{
  "allow": true,
  "query": {},
  "debug": {
    "rbac": {
      "allow": true,
      "allowing_roles": [
        "admin"
      ],
      "code": "allow",
      "reason": "user 'bob' has the role 'admin' in tenant 'default', role 'admin' has the 'create' permission on resources of type 'customers'"
    },
    "request": {
      "action": "create",
      "resource": {
        "attributes": {
          "type": "customers",
          "user_id": "123"
        },
        "type": "customers"
      },
      "tenant": "default",
      "user": {
        "attributes": {
          "key": "bob",
          "roles": [
            "admin"
          ],
          "tenants": [
            "default"
          ]
        },
        "key": "bob",
        "synced": true
      }
    }
  },
  "result": true
}

See screenshots for policy setup.

but probably not all of it... the

/allowed_url

does a single mapping between one resource and it's action. You can create a priority list of urls that match, and the top one will be the one that is evaluated, but really the goal is to provide a translation of

url + http_verb

to

resource + action

so that we can forward the request to OPA.