What is the difference between the Rate Limit and Quota policies?

 The Rate Limit and Quota policies in Apigee serve similar but distinct purposes:

Rate Limit:

• Limits the number of requests within a time window
• Used to prevent API throttling attacks
• Time windows can be sliding (resetting) or non-sliding
• Can limit by request count, bytes, or API calls per second
• Will reject requests that exceed the specified rate

Use cases:

• Preventing API abuse
• Avoiding overloading backend systems
• Throttling calls to external services

Quota:

• Sets an absolute threshold on the number of requests
• Used to ration and budget API usage
• Quota limits apply over a specified quota reset period

• Daily, weekly, monthly, etc.
  • Can be administered on a per-client basis
• Assign different quotas to different API consumers
  • Once a quota is exhausted, subsequent requests are reject

Use cases:

• Enforcing tiered service plans
• Metering API usage for billing
• Limiting "free tier" API allowances

So in summary:

• Rate Limit focuses on request rates over a time window
• Quota focuses on absolute request thresholds over a period
• Rate Limit prevents spikes and throttling
• Quota rations and budgets total API usage

Using both policies together can give you a robust approach to control API access:

• Rate Limit to prevent spikes and abuse
• Quota to enforce total allowance levels per consumer

Hope this comparison helps! Let me know if you have any other questions about Apigee's Rate Limit and Quota policies.

apigee policies

 Apigee has a wide variety of policies that can be applied to API proxies to control and modify API requests and responses:

• Rate Limit - Limits the rate of requests from clients. Helps prevent API throttling attacks.

• Quota - Sets thresholds on the number of requests clients can make over a time period.

• Cache - Stores responses to cacheable requests to reduce load on backend servers.

• Rewrite - Modifies URL paths, query parameters and headers in requests.

• JavaScript - Allows executing arbitrary JavaScript code to inspect and modify requests.

• Conditional - Applies other policies conditionally based on requests attributes.

• Latency - Measures and reports on the latency of requests.

• Log - Logs requests at different severity levels for auditing and debugging.

• OAuth - Implements OAuth 1.0a and 2.0 protocols for securing APIs.

• Trace - Generates traces to correlate requests with response latency and errors.

• XML Security - Implements XML security standards like XML Encryption and Signature.

• Fault - Generates errors and faults for testing policies and clients.

• Extract Variables - Extracts values from requests and makes them available as variables.

• Thread Local Storage - Stores request-specific data for sharing between policies.

• Callout - Allows executing external scripts or services during request processing.

• Content Security Policy (CSP) - Enforces a CSP to protect against cross-site scripting attacks.

• And many more...

These policies give Apigee a lot of flexibility and power to shape, secure, transform and control API traffic in a granular fashion. They can be chained together in any order within an API proxy to achieve the required business logic and requirements.

Moreover, Apigee allows creating custom policies by extending its open plugin model. So organizations have unlimited potential to develop domain-specific policies for their unique API management needs.

Hope this gives you a good overview of the breadth of policies available within Apigee's API management platform! Let me know if you have any other questions.

Can I set up alerts for specific API proxies?

 Yes, you can definitely configure alerts in Apigee Analytics based on specific API proxies:

When creating an alert, you have the option to filter by:

• Organization
• Environment
• API Proxy
• And optionally by other dimensions like client, method, etc.

This allows you to scope alerts to target:

• A single API proxy
• Multiple API proxies
• All API proxies

For example, you could create alerts like:

• Error rate above 5% for the "user_api" API proxy
• Request count above 1000 for the "auth_api" and "payment_api" proxies
• Latency above 500ms for any API proxy

To target a specific API proxy in an alert, just follow these steps:

1. When creating the alert, select the Organization and Environment as normal.

2. For "Filter by:", choose "API Proxy" from the drop down.

3. Enter the name of the API proxy you want to alert on.

4. You can optionally add filters by other dimensions if needed.

5. Configure the rest of the alert as normal - metric, threshold, actions, frequency, etc.

6. Save the alert.

The alert will then only use Analytics data from traffic to the specified API proxy (or proxies) when evaluating the conditions.
This allows you to scope alerting more granularly at the API proxy level, in addition to the organization and environment levels.

In summary, yes - by selecting the "API Proxy" dimension when creating an alert in Apigee Analytics, you can easily set up alerts that only target specific API proxies within your Apigee environment.

Hope this helps! Let me know if you have any other questions.

Can I set up alerts for multiple environments?

 Yes, you can absolutely set up alerts in Apigee Analytics that apply to multiple environments:

When creating an alert, there is a field where you select the Organization and Environment:

• Organization: Defaults to the one you are logged into
• Environment: You can either choose:
  • Single environment
  • All environments

By choosing "All environments", the alert will apply to:

• All existing environments in that organization
• Any new environments that are created

So you have two options for multi-environment alerts:

1. Create a separate alert for each environment
   This gives you more granular alerting, but requires managing multiple alerts.

2. Create a single alert targeting "All environments"
   This applies the same alert threshold and actions to all environments. It's simpler to manage but less tailored.

When the alert conditions are met based on Analytics data from any of the environments, the configured action (email, webhook, etc.) will be triggered.

For example, you could create:

• An alert for errors above 5% in the test environment
• An alert for requests above 10,000 per second across all environments

When either of those conditions are met in the respective environments, the corresponding alert action would fire.

The option you choose depends on your specific monitoring and alerting requirements. But Apigee does give you the flexibility to set alerts at the individual environment level, across all environments, or using a combination of both.

Hope this helps! Let me know if you have any other questions about setting up alerts in Apigee Analytics.

How can I set up alerts in Apigee Analytics?

 Here are the steps to set up alerts in Apigee Analytics:

1. Go to the Apigee Edge management UI and select "Analytics" from the left menu.

2. Click the "Alerts" tab. This shows any existing alerts.

3. Click "New alert" to create a new one.

4. Select the query type:

• Simple: For basic alerts on a single metric
• Advanced: For more complex queries across dimensions and metrics

5. Enter an alert name and description.

6. Select the organization and environment the alert applies to.

7. For a simple alert:

• Select the metric from the drop-down (e.g. error rate)
• Choose whether to alert when metric is above or below a threshold
• Enter the threshold value (e.g. 5 for 5%)
• Select for how long the threshold must be exceeded before alerting

8. For an advanced alert:

• Enter a valid Analytics query string
• Define the alert threshold using HAVING or WHERE clauses

9. Choose the alert frequency:

• Once - Alert just once when threshold is exceeded
• Every time - Alert every time the threshold is exceeded

10. Select the alert action:

• Email - Send alert to specific addresses
• Webhook - Trigger an external webhook URL

11. Save the alert.

12. When the alert conditions are met based on the Analytics data, Apigee will trigger the configured action - sending emails and/or webhook calls to notify you.

13. You can modify or delete alerts as needed from the Alerts tab in Analytics.

Hope these steps help! Let me know if you have any other questions about setting up or configuring alerts in Apigee Analytics.

How can I determine the normal performance of my API?

 Here are some ways you can determine the "normal" performance of your API as a benchmark:

1. Collect metrics and logs over time - As you first deploy your API and it sees increased usage, collect metrics like:

• Request count and throughput
• Average and 99th percentile response times
• Error rates and types of errors

2. Look for performance trends - Over days, weeks and months, look for patterns in the metrics that indicate the API's typical performance under different loads and usage scenarios.

3. Analyze log patterns - Determine the normal types and frequency of log messages your API produces when running smoothly. These become your "baseline" logs.

4. Set performance SLAs - Based on the typical performance you've observed, set Service Level Agreements for metrics like:

• Uptime percentage goal
• Average latency target
• Maximum error rate to stay within

5. Identify performance outliers - As you collect more metrics over time, look for data points that fall outside the normal performance ranges you've observed. These could indicate issues.

6. Compare to historical data - Within your monitoring system, compare current performance metrics to the same time periods in previous weeks and months. This can reveal degrading performance earlier.

7. Take into account environmental factors - Consider things like day of week, season, promotions, etc. that could cause fluctuations in your typical performance benchmarks.

8. Monitor resource usage - Track metrics like CPU, memory and network usage of your API hosts. Determine the "normal" levels required to sustain your expected API performance.

By collecting metrics, logs and resource usage data over an extended period after your API is launched, you'll gain insights into its typical performance under a variety of conditions. This historical data then serves as the benchmark for determining when current performance deviates outside normal ranges, indicating potential issues.

Hope this helps! Monitoring your API over time and continually updating your performance baselines as usage changes will give you the context needed to spot abnormal behavior and troubleshoot issues quickly.

What are the best practices for monitoring API traffic and logs?

 Here are some best practices for monitoring API traffic and logs:

• Send key metrics to a monitoring system - Send critical metrics like request count, error rate, response time, and throughput to a monitoring solution. This could be:

• Apigee's own analytics
• An external tool like Datadog, New Relic, Splunk, etc.

• Set up alerts - Within your monitoring system, set up alerts for important metrics like:

• Spikes in error rate
• Sustained high latency
• Significant traffic drops
• Abnormally high CPU usage on API hosts

• Monitor logs centrally - Send API logs to a centralized log aggregator that allows searching, filtering and correlation of logs. This could be:

• Apigee logs
• ELK Stack
• Splunk, Sumo Logic, Datadog, etc.

• Define important log patterns - Determine what common issues, errors and attacks to look for in API logs. Define patterns to search and alert on.

• Audit logs - Regularly search logs for signs of unauthorized access, data leaks or other security incidents.

• Check API health - Monitor API uptime and error rates to determine overall API health and stability.

• Set SLAs - Define Service Level Agreements for key metrics like availability, latency and error budgets to help determine "normal" API performance.

• Compare to historical data - Compare current metrics and logs to historical norms to detect any abnormal trends that indicate issues.

In summary, the keys are centralizing your logging, shipping the right metrics to a monitoring system, defining important log patterns and alerts, and benchmarking API performance to determine when issues arise. With these practices, you'll have visibility into the health, stability and security of your APIs.

Hope this gives you some good monitoring best practices to implement! Let me know if you have any other questions.

How do I validate and deploy the new revision?

 Here are the steps to validate and deploy a new API proxy revision in Apigee after merging a branch:

1. After merging the branch into the master API proxy, the new revision will be unlocked, allowing you to make changes.

2. Make any final tweaks or adjustments needed for the new feature. Test the API calls using the API proxy's test console to ensure everything is working as expected.

3. Promote the revision to a lower environment for testing. In Apigee, environments represent distinct deployment targets:

• Development
• Test
• Staging
• Production

4. Promoting a revision deploys that API proxy version to the selected environment. You'll typically want to promote to:

• Development: For the developer who created the branch
• Test: For more rigorous testing by QA or another team

5. In the lower environments, have additional teams thoroughly test the new feature by exercising all API calls and behavior.

6. If testing passes, lock the revision indicating it is ready for production use. A locked revision should only be changed in case of an emergency fix.

7. Once approved, promote the revision to higher environments:

• Staging: For final validation before production
• Production: To deploy to external clients

8. Monitor API traffic and logs after deployment to identify any issues. Be prepared to roll back to a previous stable revision if needed.

9. Over time, continuously merge new feature branches into the master API proxy to build out your API and services. But always validate and thoroughly test new revisions in lower environments before deploying to production.

That covers the basic workflow for validating, testing and deploying an API proxy revision in Apigee after merging a feature branch. Hopefully this gives you the high level process - let me know if you have any other questions!

How do I merge a branch back into the master API proxy?

 Here are the basic steps to merge a branch back into the master API proxy in Apigee:

1. Go to the API Proxies page and locate the branched API proxy.

2. Click the menu icon (3 vertical dots) and select "Merge into another API proxy".

3. Choose the API proxy you want to merge the branch into. This is typically the master branch API proxy.

4. On the next screen, select whether to:

• Merge configuration only: Only merges policy configs, no proxy endpoints or resources
• Merge all: Fully merges all configs, endpoints, and resources. In case of conflict, the target API proxy takes precedence.

5. If there are any merge conflicts (e.g. two branches modifying the same element), Apigee will show them on the next screen. You have two options:

• Select the source (branched) version to overwrite the target.
• Select the target version to keep as-is and ignore the branched version.

Resolve all conflicts this way.

6. Preview the merged API proxy. Apigee shows a diff of the changes that will be merged.

7. Click "Merge". Apigee will:

• Merge the selected configs and resources from the branch into the target API proxy
• Increment the target's revision number
• Retire the branch API proxy (if set to auto-retire during merge)

8. The target API proxy will now contain the changes from the merged branch. You can validate and deploy the new revision.

9. Repeat this process for merging additional branches into the master API proxy as needed.

Hopefully these steps help give you a clear overview of how to merge branches in Apigee! Let me know if you have any other questions about managing feature branches for your API proxies.

How do I create a new branch in Apigee?

 Here are the basic steps to create a new branch for an API proxy in Apigee:

1. Go to the API Proxies page in the Apigee Edge UI.

2. Locate the API proxy you want to branch and click the menu icon (3 vertical dots).

3. Select "Create Branch".

4. Enter a name for the new branch. This will be prefixed to the API proxy name, so make it descriptive (e.g. new_feature).

5. Choose whether the branch is based on:

• Latest deployed revision: Bases the branch on the currently deployed API revision.
• Specific revision: Allows choosing an exact historical revision to base the branch on.

6. Click "Create". This will create an exact copy of the selected API revision and assign it the branch name you specified.

7. The branched API proxy will now show up in the list with the branch name as a prefix (e.g. new_feature/my_api).

8. You can now make changes to this branched API proxy independently of the master branch.

9. When ready, deploy the changes from the branch to a test environment for validation.

10. If the changes are valid, you can merge the branch back into the master API proxy.

11. Repeat the branch/change/merge cycle as needed for each new feature or capability.

So in short, those are the high level steps to easily create a new feature branch for an API proxy in Apigee - based on choosing a base revision and giving the branch a meaningful name. Let me know if you have any other questions!

Apigee supports creating branches of API proxies to allow for feature-based development

 • Branch by Feature - In Apigee, you can create branches of an API proxy for different features or capabilities. For example:

• master branch: Main production API proxy
• new_feature branch: Version with new feature added
• bugfix_123 branch: Version for fixing a specific bug

• Independent Development - Each branch can be developed independently. Developers working on different features can work in separate branches.

• Targeting Environments - You can deploy a branch to a specific environment, like:

• master branch to production environment
• new_feature branch to test and staging environments

• Merge Changes - After testing a feature branch, you can merge the changes back into the master branch. Apigee provides tools to assist with merging branches.

• Snapshots - You can create snapshots of an API proxy to capture its state at a point in time. This allows reverting to a known good snapshot if needed.

• Isolation - Different branches are isolated, so changes in one branch do not affect others. This reduces the risk of breaking the main production API.

• Access Control - Apigee allows configuring permissions to control which users can access, deploy, and manage specific API proxy branches.

• Versioning - Apigee supports API versioning, so API proxies in different branches can implement different API versions simultaneously.

• Roll Back - If an API deployment from a branch has an issue, you can easily roll back to the previous stable version.

In summary, Apigee's branching feature - combined with its environment and deployment tools - allows for an effective feature branch workflow to manage the lifecycle of your APIs. Let me know if you have any other questions!

Can Apigee's plugins be customized to work with proprietary security solutions?

 Yes, Apigee's plugin architecture allows integrating with both public security solutions as well as proprietary/custom solutions:

Apigee plugins are implemented as Java classes that interface with Apigee's API proxy. Apigee provides a plugin API that these classes can utilize to:

• Inspect and modify API requests and responses
• Access configuration data
• Enforce policies
• Report events and metrics
• Trigger other Apigee features like rate limiting, quotas, etc.

This plugin API gives developers the ability to integrate Apigee with any custom solution that meets these interface requirements.

If an organization has developed their own proprietary security tools, they can build a customized Java plugin that:

1. Connects to their security solution through an API or SDK.

2. Retrieves security data from that solution, like blacklists, access controls, fraud alerts, etc.

3. Applies that security data and policies by calling the Apigee plugin API - for example, blocking requests based on IP address data from their solution.

4. Sends security events from Apigee to their solution for monitoring and analysis.

5. Utilizes any additional features of their security solution, customized for their specific needs.

Because the plugin architecture is based on open Java APIs, it allows integrating Apigee with essentially any security solution, whether public, private, or custom-built. Organizations have full flexibility to develop plugins that meet their unique requirements.

So in short, yes - Apigee's plugins can absolutely be customized to work with an organization's proprietary security solutions, providing a tightly integrated solution.

Hope this helps! Let me know if you have any other questions.