Merging to release-5.4: [DX-1437] organise --> organize (PR 2) (#5077)

[DX-1437] organise --> organize (PR 2) (#5077)

* organise 2

* organise fix 1

* Update tyk-docs/content/basic-config-and-security/security/dashboard/organisations.md

---------

Co-authored-by: Yaara <[email protected]>

Author: buger

tyk-docs/content/advanced-configuration/integrate/3rd-party-identity-providers/dashboard-login-ldap-tib.md

@@ -127,7 +127,7 @@ TIB ships with a default `profiles.json` file which contains many example config
 The key attributes for LDAP profile are:
 
 * `ID`: The ID by which we will activate the profile by calling the appropriate TIB endpoint
-* `OrgId`: The organisation id which the profile is connected to - make sure this is the correct id for your organisation (see the [Dashboard Admin API documentation]({{< ref "dashboard-admin-api/organisations" >}}) for details on how to retrieve this)
+* `OrgId`: The organization id which the profile is connected to - make sure this is the correct id for your organization (see the [Dashboard Admin API documentation]({{< ref "dashboard-admin-api/organisations" >}}) for details on how to retrieve this)
 * `IdentityHandlerConfig.DashboardCredential`: The Dashboard API Access credential which is used as authorization header
 * `ProviderConfig.FailureRedirect`: The URL which TIB will redirect to if the authentication fails
 * `ProviderConfig.LDAPPort`: The port through which TIB can communicate with your LDAP server

tyk-docs/content/advanced-configuration/integrate/sso.md

@@ -13,7 +13,7 @@ weight: 0
 ### SSO - The generic use case
 
 SSO gives users the ability to log in to multiple applications without the need to enter their password more than once.
-[OIDC]({{< ref "basic-config-and-security/security/authentication-authorization/openid-connect" >}}) or SAML enables an application to verify the identity of users from an organisation without the need to self store and manage them, and without doing the identification process and exposing their passwords to that application. Their lists of users and passwords are kept safe in one single place, in the IDP that the organisation has chosen to use. The Authorization server of the IdP identify the users for a pre-registered and approved application (`client` in OAuth and OIDC terminology).
+[OIDC]({{< ref "basic-config-and-security/security/authentication-authorization/openid-connect" >}}) or SAML enables an application to verify the identity of users from an organization without the need to self store and manage them, and without doing the identification process and exposing their passwords to that application. Their lists of users and passwords are kept safe in one single place, in the IDP that the organization has chosen to use. The Authorization server of the IdP identify the users for a pre-registered and approved application (`client` in OAuth and OIDC terminology).
 
 ### SSO in Tyk
 
@@ -67,7 +67,7 @@ The provider config for SAML has the following values that can be configured in
 
 `FailureRedirect` - Where to redirect failed login requests.
 
-`IDPMetaDataURL` - The metadata URL of your IDP which will provide Tyk Identity Broker with information about the IDP such as EntityID, Endpoints (Single Sign On Service Endpoint, Single Logout Service Endpoint), its public X.509 cert, NameId Format, Organisation info and Contact info.
+`IDPMetaDataURL` - The metadata URL of your IDP which will provide Tyk Identity Broker with information about the IDP such as EntityID, Endpoints (Single Sign On Service Endpoint, Single Logout Service Endpoint), its public X.509 cert, NameId Format, Organization info and Contact info.
 
 This metadata XML can be signed providing a public X.509 cert and the private key.     
 

tyk-docs/content/apim-best-practice/api-security-best-practice/governance.md

@@ -5,7 +5,7 @@ tags: ["API Security", "governance"]
 description: "Management and governance of APIs"
 ---
 
-APIs need to be managed and governed just like any other resource, otherwise organisations risk losing track of their API estate and becoming unaware of potentially vulnerable APIs running within their infrastructure. This risk is magnified as the number of teams, environments and APIs increases. Use API management as part of overarching business processes to control how APIs are accessed, managed and deployed.
+APIs need to be managed and governed just like any other resource, otherwise organizations risk losing track of their API estate and becoming unaware of potentially vulnerable APIs running within their infrastructure. This risk is magnified as the number of teams, environments and APIs increases. Use API management as part of overarching business processes to control how APIs are accessed, managed and deployed.
 
 **Restrict Version Availability**: Enforce the expiry of [API versions]({{< ref "getting-started/key-concepts/versioning" >}}) that are planned for deprecation, by setting a sunset date, beyond which they will not be accessible.
 

tyk-docs/content/basic-config-and-security/report-monitor-trigger-events/event-types.md

@@ -15,8 +15,8 @@ The events currently raised by Tyk are:
 
 *   `QuotaExceeded`: Quota for a specific key has been exceeded
 *   `RatelimitExceeded`: Rate limit has been exceeded for a specific key
-*   `OrgQuotaExceeded`: Quota for a specific organisation has been exceeded
-*   `OrgRateLimitExceeded`: Rate limit has been exceeded for a specific organisation
+*   `OrgQuotaExceeded`: Quota for a specific organization has been exceeded
+*   `OrgRateLimitExceeded`: Rate limit has been exceeded for a specific organization
 *   `AuthFailure`: A key has failed authentication or has attempted access and was denied
 *   `KeyExpired`: A key has attempted access but is expired
 *   `VersionFailure`: A key has attempted access to a version it does not have permission to access

tyk-docs/content/basic-config-and-security/report-monitor-trigger-events/monitors.md

@@ -9,7 +9,7 @@ menu:
 weight: 5 
 ---
 
-Tyk enables you to actively monitor both users and organisation quotas. The machinery that manages these active notifications is the same as webhooks and provides an easy way to notify your stakeholders, your own organisation or the API end user when certain thresholds have been reached for their token.
+Tyk enables you to actively monitor both users and organization quotas. The machinery that manages these active notifications is the same as webhooks and provides an easy way to notify your stakeholders, your own organization or the API end user when certain thresholds have been reached for their token.
 
 ## Enabling Monitors In Your Tyk Node?
 
@@ -43,11 +43,11 @@ From Dashboard v1.8.2, if you are using our [Developer Portal]({{< ref "tyk-deve
 
 
 *   `monitor_user_keys`: Set to `true` to monitor individual tokens, this may result in a large amount of webhooks.
-*   `monitor_org_keys`: Set to `true` to have global organisation quotas monitored.
+*   `monitor_org_keys`: Set to `true` to have global organization quotas monitored.
 
-## Setting custom triggers on a per-key or a per-organisation basis
+## Setting custom triggers on a per-key or a per-organization basis
 
-Sometimes you will not want to have every user have a trigger event at the same levels, you can set manual trigger levels by adding a `monitor` section to the Session Object that defines a key's access details, this can also be added to the session object of an organisation ID:
+Sometimes you will not want to have every user have a trigger event at the same levels, you can set manual trigger levels by adding a `monitor` section to the Session Object that defines a key's access details, this can also be added to the session object of an organization ID:
 
 ```json
 "monitor": {
@@ -71,4 +71,4 @@ The webhook payload will take the following format:
 }
 ```
 
-If the event is triggered by an organisation, then the `key` field will be empty, if it is an auth token, then the `key` field will have raw representation of the token that caused the quota trigger to fire.
+If the event is triggered by an organization, then the `key` field will be empty, if it is an auth token, then the `key` field will have raw representation of the token that caused the quota trigger to fire.

tyk-docs/content/basic-config-and-security/security/authentication-authorization/basic-auth.md

@@ -135,7 +135,7 @@ curl -X POST -H "x-tyk-authorization: 352d20fe67be67f6340b4c0605b044c3" \
 
 You use `POST` to create a new user and `PUT` to update an existing entry.
 
-Be careful to ensure that the `org_id` is set correctly and consistently so that the Basic Authentication user is created in the correct organisation.
+Be careful to ensure that the `org_id` is set correctly and consistently so that the Basic Authentication user is created in the correct organization.
 {{< /note >}}
 
 ### Using the Tyk Dashboard API
@@ -180,7 +180,7 @@ curl -X POST -H "Authorization: 907aed9f88514f175f1dccf8a921f741"
 
 You use `POST` to create a new user and `PUT` to update an existing entry.
 
-Be careful to ensure that the `org_id` is set correctly and consistently so that the Basic Authentication user is created in the correct organisation.
+Be careful to ensure that the `org_id` is set correctly and consistently so that the Basic Authentication user is created in the correct organization.
 {{< /note >}}
 
 ## Extracting credentials from the request body

tyk-docs/content/basic-config-and-security/security/dashboard.md

@@ -9,4 +9,4 @@ menu:
 weight: 3
 ---
 
-The Tyk Dashboard is a key system in Tyk that has multiple security options and concepts. In particular, this section covers how Tyk Dashboard's security model is organised, its key components and how you can interact with them to apply security settings to your dashboard in various contexts.
+The Tyk Dashboard is a key system in Tyk that has multiple security options and concepts. In particular, this section covers how Tyk Dashboard's security model is organized, its key components and how you can interact with them to apply security settings to your dashboard in various contexts.

tyk-docs/content/basic-config-and-security/security/dashboard/organisations.md

@@ -1,39 +1,39 @@
 ---
 date: 2017-03-23T14:40:22Z
-title: Organisations
-tags: ["Organisations", "Dashboard", "API governance", "Admin API"]
-description: "How organisations are created and used with the Tyk Dashboard"
+title: Organizations
+tags: ["Organizations", "Dashboard", "API governance", "Admin API"]
+description: "How organizations are created and used with the Tyk Dashboard"
 menu:
   main:
     parent: "Dashboard"
 weight: 1 
 ---
 
-Many businesses have a complex structure, for example a lot of distinct departments where each department has its own teams. You might also need to deploy and manage multiple environments such as Production, Staging and QA for different stages in your product workflow. The Tyk Dashboard is multi-tenant capable which allows you to use a single Tyk Dashboard to host separate *organisations* for each team or environment.
+Many businesses have a complex structure, for example a lot of distinct departments where each department has its own teams. You might also need to deploy and manage multiple environments such as Production, Staging and QA for different stages in your product workflow. The Tyk Dashboard is multi-tenant capable which allows you to use a single Tyk Dashboard to host separate *organizations* for each team or environment.
 
-An Organisation is a completely isolated unit, and has its own:
+An Organization is a completely isolated unit, and has its own:
  - API Definitions
  - API Keys
  - Users
  - Developers
  - Domain
  - Tyk Classic Portal 
 
-When bootstrapping your Dashboard, the first thing the bootstrap script does is to create a new default Organisation.
+When bootstrapping your Dashboard, the first thing the bootstrap script does is to create a new default Organization.
 
-Additional organisations can be created and managed using the [Dashboard Admin API]({{< ref "dashboard-admin-api/organisations" >}}).
+Additional organizations can be created and managed using the [Dashboard Admin API]({{< ref "dashboard-admin-api/organisations" >}}).
 
-### Tyk Gateway and organisations
-The concept of an organisation does not exist within the Tyk Gateway. Gateways only proxy and validate the rules imposed on them by the definitions and keys that are being processed, however at their core there are some security checks within the Gateway that ensure organisational ownership of objects.
+### Tyk Gateway and organizations
+The concept of an organization does not exist within the Tyk Gateway. Gateways only proxy and validate the rules imposed on them by the definitions and keys that are being processed, however at their core there are some security checks within the Gateway that ensure organizational ownership of objects.
 
-Tyk allows each organisation to own its own set of Gateways, for example when you want to use different hosting providers you can segregate them in terms of resources, or just for security reasons.
+Tyk allows each organization to own its own set of Gateways, for example when you want to use different hosting providers you can segregate them in terms of resources, or just for security reasons.
 
-Self-Managed users should use [API tagging]({{< ref "advanced-configuration/manage-multiple-environments/with-tyk-on-premises" >}}) and enforce a tagging standard across all organisations.
+Self-Managed users should use [API tagging]({{< ref "advanced-configuration/manage-multiple-environments/with-tyk-on-premises" >}}) and enforce a tagging standard across all organizations.
 
-All actions in a Self-Managed installation of Tyk must use a base Organisation, and all actions should stem from a User owned by that organisation.
+All actions in a Self-Managed installation of Tyk must use a base Organization, and all actions should stem from a User owned by that organization.
 
 {{< note success >}}
 **Note**
 
-A user that does not belong to an Organisation is sometimes referred to as an *unbounded user*. These users have visibility across all Organisations, but should be granted read-only access.
+A user that does not belong to an Organization is sometimes referred to as an *unbounded user*. These users have visibility across all Organizations, but should be granted read-only access.
 {{< /note >}}

tyk-docs/content/basic-config-and-security/security/key-hashing.md

@@ -30,7 +30,7 @@ To set a custom algorithm, you need to set `hash_key_function` in your `tyk.conf
 * `murmur128`
 * `sha256`
 
-MurMur non-cryptographic hash functions are considered as the industry fastest and conflict-prone algorithms up to date, which gives a nice balance between security and performance. With this change you now you can choose the different hash length, depending on your organisation security policies. We have also introduced a new `sha256` cryptographic key hashing algorithm, for cases when you are willing to sacrifice some performance for additional security.
+MurMur non-cryptographic hash functions are considered as the industry fastest and conflict-prone algorithms up to date, which gives a nice balance between security and performance. With this change you now you can choose the different hash length, depending on your organization security policies. We have also introduced a new `sha256` cryptographic key hashing algorithm, for cases when you are willing to sacrifice some performance for additional security.
 
 Performance wise, setting new key hashing algorithms can increase the key hash length, as well as key length itself, so expect that your analytics data size to grow (but not that much, up to about 10%). Additionally, if you set the `sha256` algorithm, it will significantly slowdown Tyk, because cryptographic functions are slow by design but very secure.
 

tyk-docs/content/basic-config-and-security/security/mutual-tls/concepts.md

@@ -70,9 +70,9 @@ Returns array of meta info objects, similar to above.
 The Dashboard Admin API is very similar, except for a few minor differences:
 
 * Endpoints start with `/api` instead of `/tyk`, e.g. `/api/certs`, `/api/certs/<cert-id>`, etc.
-* All certificates are managed in the context of the organisation. In other words, certificates are not shared between organisations.
+* All certificates are managed in the context of the organization. In other words, certificates are not shared between organizations.
 
-Certificate storage uses a hex encoded certificate SHA256 fingerprint as its ID. When used with the Dashboard API, Tyk additionally appends the organisation id to the certificate fingerprint. It means that certificate IDs are predictable, and you can check certificates by their IDs by manually 
+Certificate storage uses a hex encoded certificate SHA256 fingerprint as its ID. When used with the Dashboard API, Tyk additionally appends the organization id to the certificate fingerprint. It means that certificate IDs are predictable, and you can check certificates by their IDs by manually 
 generating certificate SHA256 fingerprint using the following command:
 
 ```{.copyWrapper}

tyk-docs/content/basic-config-and-security/security/owasp-top-ten.md

@@ -120,7 +120,7 @@ In addition, it is best practice to consider any definition of done to include c
 
 Attackers may identify and target the third party APIs/services used by an API. This can lead to leaked sensitive information, denial of service, injection attacks etc.
 
-It is the responsibility of the API to provide protection against these attacks. However, if the organisation uses the Gateway as a forwarding proxy to third party APIs, then the following features could be used:
+It is the responsibility of the API to provide protection against these attacks. However, if the organization uses the Gateway as a forwarding proxy to third party APIs, then the following features could be used:
 
 - [JSON Schema validation]({{< ref "product-stack/tyk-gateway/middleware/validate-request-tyk-classic" >}}) to validate that an incoming data payload meets a defined schema. Payloads that do not adhere to the schema are rejected.
 - [TLS]({{< ref "basic-config-and-security/security/tls-and-ssl" >}}) to ensure that clients use the right service and encrypt traffic.

tyk-docs/content/deployment-and-operations/tyk-self-managed/deployment-lifecycle/deployment-to-production/key-value-storage/vault.md

@@ -39,7 +39,7 @@ Alternatively, you can configure it using the equivalent [environment variables]
 
 ### How key-value data is stored in Vault
 
-In traditional systems secrets are typically stored individually, each with their own unique key. Vault, however, allows for a more flexible approach where multiple *keys* can be grouped together and stored under a single *secret*. This grouping allows for better organisation and management of related secrets, making it easier to retrieve and manage them collectively.
+In traditional systems secrets are typically stored individually, each with their own unique key. Vault, however, allows for a more flexible approach where multiple *keys* can be grouped together and stored under a single *secret*. This grouping allows for better organization and management of related secrets, making it easier to retrieve and manage them collectively.
 
 When retrieving data from Vault, you use the dot notation (`secret.key`) to access the *value* from a specific *key* within a *secret*.
 

tyk-docs/content/graphql/creating-gql-api.md

@@ -76,7 +76,7 @@ Your GQL API is now secured and ready to use.
 
 It is possible to create GQL APIs using [Tyk Dashboard APIs]({{< ref "/tyk-apis/tyk-dashboard-api/api-definitions">}}). To make things easier you can use our [Postman collection](https://www.postman.com/tyk-technologies/workspace/tyk-public-workspace/overview).
 
-You will need an API key for your organisation and one command to create a GQL API and make it live.
+You will need an API key for your organization and one command to create a GQL API and make it live.
 ### Obtain your Tyk Dashboard API Access Credentials key & Dashboard URL
 
 From the Tyk Dashboard, select "Users" from the "System Management" section.

tyk-docs/content/plugins/how-to-serve-plugins/plugin-bundles.md

@@ -154,7 +154,7 @@ A complete API Definition would look like:
 ## Downloading and Updating Bundles
 Tyk will fetch `http://my-bundle-server.com/bundles/bundle-latest.zip` on start. A plugin bundle will be cached after its initial download, if a Tyk reload event occurs, the same contents will be used. If you want to replace it, you must update your API configuration to use a different name and then trigger a reload.
 
-As a suggestion, you may organise this using a Git commit reference or version number, e.g. `bundle-e5e6044.zip`, `bundle-48714c8.zip`, `bundle-1.0.0.zip`, `bundle-1.0.1.zip`, etc.
+As a suggestion, you may organize this using a Git commit reference or version number, e.g. `bundle-e5e6044.zip`, `bundle-48714c8.zip`, `bundle-1.0.0.zip`, `bundle-1.0.1.zip`, etc.
 
 Alternatively, you may delete the cached bundle from Tyk manually and then trigger a hot reload to tell Tyk to fetch a new one.  By default, Tyk will store downloaded bundles in this path:
 `{ TYK_ROOT } / { CONFIG_MIDDLEWARE_PATH } / bundles`