Creating Governance Rules

With API governance, you can create rules that automatically enforce quotas or restrict access to your APIs. For example, if you are monetizing your API with a prepaid billing model, you can create a governance rule to block access when a customer’s balance goes below zero dollars. You can also use governance to protect your APIs such as to block scraping an abnormally large amount of data from your API.

Accessing Governance Rules

To access API governance rules, click on Governance Rules in the left-side navigation menu.

To easily create a new Governance Rule, click the Create New button and select Governance Rule

It’s important to remember that newly created governance rules are set to “off” by default. They must be turned to “on” in order to be enabled.

Types of rules

Governance is incompatible with the Tyk, Azure APIM, and AWS API Gateway integrations. Please check with your customer success representative if governance is supported for your server integration.

User Rules

A user rule is one that is applied to all users that is a member of a behavioral cohort. You can create behavioral cohorts that match any criteria and behavior such as API access patterns, customer demographics, and more.

Examples of ways to leverage user rules include:

• “Block users with many 401 unauthorized errors in last 7 days”
• “Block users who accessed over 100 items in an hour”

You can also add regex criteria so your rule only applies to specific requests.

Company Rule

A company rule is very similar to a user rule except it blocks an entire company. Examples of ways to leverage company rules include: If a request matches both a user and company rule, the user rule takes priority.

• “Block companies with overdue invoices”
• “Block companies who exceeded plan quotas”

Like user rules, you can also add regex criteria so your rule only applies to specific requests.

Regex Rule

Unlike user and company rules, regex rules apply to all API requests regardless if the request was authenticated. This enables blocking or applying goverernace for specific URIs, status codes, and more. Example of regex rules include:

• “Add a X-API-Warn deprecation header for all requests to /v1/old”
• “Block all requests to /my-super-secret-endpoint”

Creating a rule

To create a new rule, navigate to the Governance Rules screen and click the Add New button. From the dropdown, select New User Rule or New Company Rule if you want to block specific customers based on behavior.

If you want to only govern based on request info regardless of the customer behavior (such as unauthenticated requests), select New Regex Rule.

Let’s walk through an example creating a User Rule to block API access to companies with overdue invoices. We also want to let them know that they are blocked due to their subscription being paused.

Once the rule is created, by clicking Create in the top right corner of the Create New Governance Rule screen, you’ll need to insure that the rule is turned on. By default, a new governance rule is not enabled.

Apply To Companies/Users

These are the saved cohorts that you want to apply the rule to.

A saved cohort is a dynamic list of users (or companies) that performed some behavior in terms of API calls and user actions. You can also match on any custom metadata you store with the profiles such as subscription or billing info. New cohort rules can be created from user lookup or company lookup panel.

Regex Criteria

By default, the rule will apply to all requests from customers in your target cohorts. You can selectively enable the rules for specific requests regex rules such as a specific URI.

Blocking vs Non-blocking

If a rule is blocking, this means Moesif will actively block the customer’s requests before getting to your upstream service. Moesif will also override the response HTTP status and body to whatever the rule is configured for.

If a rule is non-blocking, this means the request will still continue to your upstream service. Moesif will only override any HTTP response headers, but will leave the body and status code alone (passthrough).

Override Response Status

If set to blocking, this enables a way to override the response status such as an error code. In this example, we set it to 429 Payment Required

Override Response Headers

You can override any number of HTTP response headers. If the header was already set by the upstream service, Moesif will override the existing one. Otherwise, Moesif will add new headers.

Override Response Body

If set to blocking, you can override the body that will be responded to the client. This supports merge tags from the user or company profile. In our example, we add an error message explaining to the user why they are blocked. We also mentioned which plan they are on that has overdue invoices.